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Kubernetes Handbook 


Kubernetes 是 Google 基 于 Borg 开 源 的 容器 编排 调度 引擎 ， 作 为 CNCF (Cloud 
Native Computing Foundation) 最 重要 的 组 件 之 一 ， 它 的 目标 不 仅仅 是 一 个 编排 系 
统 ， 而 是 提供 一 个 规范 ， 可 以 让 你 来 描述 集群 的 架构 ， 定 义 服 务 的 最 终 状态 ， 
kubernetes 可 以 帮 你 将 系统 自动 地 达到 和 维持 在 这 个 状态 。Kubernetes 作 为 云 原生 
应 用 的 基石 ， 相 当 于 一 个 云 操作 系统 ， 其 重要 性 不 言 而 喻 。 


本 书记 录 了 本 人 从 零 开 始 学 习 和 使 用 Kubernetes 的 心路 历程 ， 着 重 于 经 验 分 享 和 总 
结 ， 同 时 也 会 有 相关 的 概念 解析 ， 希 望 能 够 帮助 大 家 少 躁 坑 ， 少 走 弯路 ， 还 会 指引 
大 家 关于 关注 kubernetes 生 态 周 边 ， 如 微服 务 构建 、DevOps、 大 数据 应 用 、 
Service Mesh、Cloud Native 等 领域 。 


本 书 的 主题 不 仅 限 于 Kubernetes， 还 包括 以 下 几 大 主题 : 


e 云 原 生 应 用 与 微服 务 架 构 
e 将 微服 务 与 Service mesh 架 构 的 代码 级 呈现 
e Kubernetes 与 微服 务 结 合 实践 


起 初 写作 本 书 时 ， 实 装 的 所 有 组 件 、 所 用 示例 和 操作 等 站 基于 Kubernetes1.6+ 版 
本 ， 同 时 我 们 也 将 密切 关注 Kubernetes 的 版 本 更 新 ， 随 着 它 的 版 本 更 新 升级 ， 本 书 
中 的 kubernetes 版 本 和 示例 也 将 随 之 更 新 。 


GitHub 地 址 : https://github.com/rootsongjc/kubernetes-handbook 


Gitbook 在 线 浏览 : https://jimmysong.io/kubernetes-handbook/ 
页 献 与 致谢 

感谢 大 家 对 本 书 做 出 的 贡献 ! 
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社区 & 读 者 交流 


e 微 信 群 : K8S&Cloud Native 实 战 ， 扫 描 我 的 微 信 二 维 码 ，Jimmy Song * XB 
接 搜 索 微 信号 jimmysong 后 拉 您 入 群 ， 请 增加 备注 (姓名 -公司 /学 校 /博客 /社区 / 
研究 所 /机 构 等 ) 。 

e Slack : 全 球 中 文 用 户 可 以 加 入 Kubernetes 官 方 Slack 中 文 频道 cn-users 
channel 

e 知 乎 专栏 : 云 原 生 应 用 架构 

e 微 信 公众 号 : 扫描 下 面 的 二 维 码 关注 微 信 公众 号 CloudNativeGo ( 云 原 生 应 用 
架构 ) 





支持 本 书 


为 贡献 者 加 油 口 ! 为 云 原生 干杯 口 ! 


























使 用 微 信 扫 一 扫 请 贡献 者 喝 一 杯 


A 

“9 MAD S ih. " 

PN . ^ 

vut N —— ao 

es =: ic 
era am t. ot 
S e WO 


"Cheers! fp” 


Copyright © jimmysong.io 2017-2018 all right reserved > powered by 
GitbookUpdated at 2018-05-09 14:15:47 


CNCF - 云 原 生计 算 基 金 会 简介 


CNCF - 云 原生 计算 基金 会 简介 


CNCF， 全 称 Cloud Native Computing Foundation ( 云 原生 计算 基金 会 ) ， 口 号 是 
坚持 和 整合 开源 技术 来 让 编排 容器 作为 微服 务 架 构 的 一 部 分 ， 其 作为 致力 于 云 原 生 
应 用 推广 和 普及 的 一 支 重 要 力量 ， 不 论 您 是 云 原生 应 用 的 开发 者 、 管 理 者 还 是 研究 
人 员 都 有 必要 了 解 。 


CNCF 作 为 一 个 厂商 中 立 的 基金 会 ， 致 力 于 Github 上 的 快速 成 长 的 开源 技术 的 推 
广 ， 如 Kubernetes、Prometheus、Envoy 等 ， 帮 助 开发 人 员 更 快 更 好 的 构建 出 色 的 
产品 。 


下 图 是 CNCF 的 全 景 图 。 


Cloud Native Landscape See the interactive landscape at l.cncf.io 


es Aplati ago 
Database and Data Warehouse. Streaming je Build Continuous Integration / Continuous Delivery (CI/CD) 


© rod 





“a. oaa | [ORC | SD || SH *9 s * 


ww Ô 


9 5 mmi -a " E 


ceph 


peni 


ot 
"ron 





nat Bd CLOUD NATIVE 
Landscape 





图 片 - CNCF landscape 


其 中 包含 了 CNCF 中 托管 的 项 目 ， 还 有 很 多 是 非 CNCF 项 目 。 


关于 CNCF 的 使 命 与 组 织 方式 请 参考 CNCF 完 章 ， 概 括 的 讲 CNCF 的 使 命 包括 以 下 三 
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e 通过 中 心 编 排 系统 的 动态 资源 管理 。 
e 面向 微服 务 。 


CNCF 这 个 角色 的 作用 是 推广 技术 ， 形 成 社区 ， 开 源 项 目 管理 与 推进 生态 系统 健康 
发 展 。 


另外 CNCF 组 织 由 以 下 部 分 组 成 : 


° : 白金、 金牌、 银牌、 最 终 用 户 、 学 术 和 非 赢利 成 员 ， 不 同 级 别 的 会 员 在 
P202 ee a 

。 理事 会 : 负责 事务 管理 

。TOC (技术 监督 委员 会 ) : 技术 管理 

e 最 终 用 户 社区 : 推动 CNCF 技 术 的 采纳 并 选举 最 终 用 户 技 术 咨 询 委 员 会 

e 最 终 用 户 技 术 咨 询 委 员 会 : 为 最 终 用 户 会 议 或 向 理事 会 提供 咨询 

e 营销 委员 会 : 市 场 推广 


CNCF 项 目 成 熟 度 分 级 与 毕业 条 件 


每 个 CNCF 项 目 都 需要 有 个 成 熟 度 等 级 ， 申 请 成 为 CNCF 项 目的 时 候 需要 确定 项 目 
的 成 熟 度 级 别 。 


成 熟 度 级 别 (Maturity Level) 包括 以 下 三 种 : 


e inception (初级 ) 
e incubating (414v F ) 
e graduated (毕业 ) 


是 否 可 以 成 为 CNCF 项 目 需要 通过 Technical Oversight Committee (技术 监督 委员 
会 ) 简称 TOC， 投 票 采取 fallback 策 略 ， 即 回 退 策略 ， 先 从 最 高 级 别 (graduated) 
开始 ， 如 果 2/3 多 数 投票 通过 的 话 则 确认 为 该 级 别 ， 如 果 没 通过 ve ， 则 进行 下 一 低 
级 别 的 投票 ， 如 果 一 直到 inception 级 别 都 没 得 到 2/3 多 数 投票 通过 的 话 ， 则 拒绝 其 进 
入 CNCF 项 目 。 


当前 所 有 的 CNCF 项 目 可 以 访问 https:/www.cncf.io/projects/ ° 


项 目 所 达到 相应 成 熟 度 需 要 满足 的 条 件 和 投票 机 制 见 





CNCF Graduation Criteria v1.0 add value 
ASL 2.0 license 


transfer trademarks to CNCF 
vote with TOC every 12 month 


less than 2/3 vote proposed 





at least 3 end users 


healthy number of committers 
ongoing flows of commits and contributions 
TOC has final judegement 





less than 2/3 less than 2/3 


i 


committers at least from two organizations 
Core Infrastructure Initiative Best Practices Badge 
GOVERNANCE.md and OWNERS.md 
ADOPTERS.md or logos 
Drafting by https://jimmysong.io normally expected to graduate within two years 
Source https:;//www.cnct.io/projects/graduation-criteria/ 








EA - CNCF 项 目 成 熟 度 级 别 


TOC (技术 监督 委员 会 ) 


TOC (Technical Oversight Committee) 作为 CNCF 中 的 一 个 重要 组 织 ， 它 的 作用 


日 


元 : 


e 定义 和 维护 技术 视野 

e 审批 新 项 目 加 入 组 织 ， 为 项 目 设 定 概念 架构 
e 接受 最 终 用 户 的 反馈 并 映射 到 项 目 中 

e 调整 组 件 见 的 访问 接口 ， 协 调 组 件 之 问 兼容 性 


TOC 成 员 通过 选举 产生 ， 见 选举 时 间 表 。 


参考 CNCF TOC : https://github.com/cncf/toc 


参考 


e https://www.cncf.io 


CNCF - 云 原 生计 算 基 金 会 简介 


e https://www.cncf.io/projects/graduation-criteria/ 
e https://www.cncf.io/about/charter/ 

e https://github.com/cncf/landscape 

e https://github.com/cncf/toc 
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Play with Kubernetes 
本 书 的 主角 是 Kubernetes， 在 开始 后 面 几 章 的 长 篇 大 论 之 前 让 大 家 可 以 零 基础 上 
手 ， 揭 开 Kubernetes 的 神秘 面纱 。 


本 文 不 是 讲解 Kubernetes 的 高 深 原理 也 不 是 讲 Kuberentes 的 具体 用 法 ， 而 是 通过 
Play with Kubernetes 来 带 您 进入 Kubernetes 的 世界 ， 相 当 于 Kubernetes 世 界 

的 “Hello World" ! 而 且 除 了 一 台 可 以 上 网 的 电脑 和 浏览 器 之 外 不 需要 再 准备 任何 东 
西 ， 其 至 (至 少 目前 为 止 ) 不 需要 注册 账号 ， 上 手 即 玩 。 


当然 免费 使 用 也 是 有 限制 的 ， 当 前 的 限制 如 下 : 


e 内 置 kubeadm 来 创建 kubernetes 集 群 ， 版 本 为 v1.8.4 

e 每 个 实例 配置 为 1core，4G Memory， 最 多 创建 5 个 实例 

e 每 个 集群 的 使 用 时 间 是 4 个 小 时 (当然 你 可 以 同时 启动 多 个 集群 ， 根 据 浏 览 器 
的 session 来 判断 集群 ) 

e 在 Kubernetes 和 集群 中 创建 的 服务 无 法 通过 外 网 访问 ， 只 能 在 Play with 
Kubernetes 的 网 络 内 访问 


登陆 Play with Kubernetes， 点 击 【 登 陆 】-【 开 始 】 即 可 开始 你 的 Kubernetes 之 
旅 ! 


创建 Kubernetes 集 群 
启动 第 一 个 实例 作为 Master 节 点 ， 在 Web 终 端 上 执行 : 


1. 初始 化 master 节 点 : 
kubeadm init --apiserver-advertise-address $(hostname -i) 
1. 初始 化 集群 网 络 : 


kubectl apply -n kube-system -f  "https://cloud.weave.works/k8s/ 
net?k8s-version-$(kubectl version | base64 | tr -d '\n')" 


1. 执行 下 列 初 始 化 命令 : 


mkdir -p $HOME/.kube 
cp -i /etc/kubernetes/admin.conf $HOME/.kube/config 
chown $(id -u):$(id -g) $HOME/.kube/config 


1. 启动 新 的 实例 作为 node 节 点 ， 根 据 master 节 点 上 的 提示 ， 在 新 的 Web 终 端 上 执 


A 


~ 


kubeadm join --token 513212.cfea0165b8988d18 192.168.0.13:6443 - 
-discovery-token-ca-cert-hash sha256:b7b6dcc98f3ead3f9e363cb3928 
fbc04774ee0d63e8eb2897ae30e05aebf 8070 


注意 : 192.168.0.13 是 master 节 点 的 IP， 请 替换 您 的 master 节 点 的 实际 IP © 
再 添加 几 个 实例 ， 重 复 执 行 第 四 步 ， 即 可 向 Kubernetes 集 群 中 增加 节点 。 


此 时 在 master 节 点 上 执行 kubect1 get nodes 查看 节点 所 有 节点 状态 ， 并 创建 
nginx deployment， 如 下 图 所 示 : 





[ Docker Playground x 
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CLOSE SESSION 


Instances 





e 192.168.0.23 
~ node1 
o 192.168.0.22 
D node2 
o 192.168.0.21 
a node3 
o 192.168.0.20 
D node4 


b9i7nrtd_b9i70i5duh0g00acamo0 


IF 
31147 
192.168.0.23 


Memory 


41.31% (1.614GiB / 3.906GiB) 


DELETE 


[nodel /]$ kubectl get nodes 
AME STATUS ROLES AGE 
Ready master 10m 
Ready <none> 8m 
Ready <none> 6m 
Ready <none> 6m 
[nodel /]$ kubectl apply -f https 
service "my-nginx-svc" created 
deployment "my-nginx" created 
[nodel /]$ kubectl get pods 
READY 
my -nginx-569477d6d8-78dsp 0/1 
my-nginx-569477d6d8-jzkmb 0/1 
imy-nginx-569477d6d8-ks48g 0/1 
[nodel /]$ kubectl get pods 
READY 
my-nginx-569477d6d8-78dsp 1/1 
my-nginx-569477d6d8-jzkmb 1/1 
Iy-nginx-569477d6d8-ks48g 1/1 





CPU 
13.14% 


VERSION 
v1.8.4 
v1.8.4 
v1.8.4 
v1.8.4 


://k8s.io/docs/user-guide//nginx-app.yaml 


STATUS RESTARTS 
ContainerCreating 0 
ContainerCreating 0 
ContainerCreating 0 


STATUS RESTARTS 
Running 0 
Running 0 
Running 0 


图 片 - Play with Kubernetes 网 页 截图 


Play with Kuberentes (PWK) is a project hacked by Marcos Lilljedahl and 


Jonathan Leibiusky and sponsored by Docker Inc. 


Copyright © jimmysong.io 2017-2018 all right reserved > powered by 
GitbookUpdated at 2018-05-09 14:15:47 


Kubernetes 与 云 原生 应 用 概览 


几 个 月 前 Mesos 已 经 宣布 支持 kubernetes， 而 在 2017 年 10 月 份 的 DockerCon EU 上 
Docker 公 司 宣布 同时 官方 支持 Swarm 和 Kubernetes 容 器 编排 ，kubernetes 已 然 成 为 
容器 编排 调度 的 标准 。 

作为 全 书 的 开头 ， 首 先 从 历史 、 生 态 和 应 用 角度 介绍 一 下 kubernetes 与 云 原生 应 

用 ， 深 入 浅 出 ， 高 屋 建 领 ， 没 有 深入 到 具体 细节 ， 主 要 是 为 了 给 初次 接触 
kubernetes 的 小 白 扫 育 ， 具 体 细 节 请 参考 链接 。 


从 云 计 算 到 微服 务 再 到 云 原生 计算 


下 面 将 从 云 计 算 的 发 展 历程 引入 云 原 生计 算 ， 请 先 看 下 图 : 


* Cloud native computing uses an open source 


C LO U D NAT IVE software stack to: 


COMPUTING FOUNDATION x . : 
— deploy applications as microservices, 


— packaging each part into its own container 


CONTAINER — and dynamically orchestrating those containers to 
O p E N INITIATIVE optimize resource utilization 


e Standardization: https://www.opencontainers.org/ 





Non 
Virtualized Virtualiza- 


Hardware tion 





webservices™ docker 


49 Sun vmware: «ámazon (H]wenoxu openstack «reos QB p sovo nanye 


CLOUD NATIVE 


COMPUTING FOUNDATION 


云 原 生 应 用 到 2020 年 将 比 目 前 至 少 翻 一 番 ， 下 图 是 Marc Wilczek 的 调查 报告 。 


Kubernetes 与 云 原 生 应 用 概览 


Cloud native comes of age 


Cloud-native applications are driving a transformative shift. We spoke to 902 
business and IT leaders to see how cloud native is changing their organizations. 


Development of cloud-native apps will What are cloud-native apps and why 
more than double by 2020 are businesses using them? 
* DovOps 
* Microservices 
Containers 
ue 
nD comme ES, SR SEE 
usiness Cos! of now 
TOOAY 2020 ME. Soo E MAE. more quickty E pra y p 
ClOs need to win over CEOs. Leading IT The more apps a business builds in the cloud, 
functions prioritize differently to business leaders. the further ahead of their peers they feel 
Cloud-nativo loadors' IT peioritios Businoss prioritios for tho IT function 
Have improved the agility Have enabled us to Have reduced our 
of our organization provide a better experience development and/or 
Customer experience Qo IT cost reduction o to our customers operating costs 








Business agility Qo Customer experience Qo 
88« 87% 
IT cost reduction @ 
Laggards Leaders 


Y Application development 


š i TR 2 is moving fully into the 
What's holding the cloud-native laggards back? cloud, and the days of 


Qo 


e a ^ traditional, monolithic 
architecture are numbered. 
70% Skills 654 Culture 
To find out more, download our T 
Legacy IT Vendor lock in Cloud native comes of age: 
A e What businesses need to know. 


图 片 - & 8 Twitter @MarcWilczek 


云 计 算 介 绍 


云 计 算 包 含 的 内 容 十 分 繁杂 ， 也 有 很 多 技术 和 公司 牵强 附会 说 自己 是 云 计 算 公 司 ， 
说 自己 是 做 云 的 ， 实 际 上 可 能 风 马 牛 不 相 及 。 说 白 了 ， 云 计算 就 是 一 种 配置 资源 的 
方式 ， 根 据 资 源 配 置 方式 的 不 同 我 们 可 以 把 云 计 草 从 宏观 上 分 为 以 下 三 种 类 型 : 


laaS : 这 是 为 了 想 要 建立 自己 的 商业 模式 并 进行 自 定 义 的 客户 ， 例 如 亚马逊 的 
EC2、S3 存 储 、Rackspace 庶 拟 机 等 都 是 laaS 。 
e PaaS: 工具 和 服务 的 集合 ， 对 于 想 用 它 来 构建 自己 的 应 用 程序 或 者 想 快 速 得 
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将 应 用 程序 部 署 到 生产 环境 而 不 必 关心 底层 硬件 的 用 户 和 开发 者 来 说 是 特别 有 
用 的 ， 比 如 Cloud Foundry ` Google App Engine ` Heroku-¥ ° 

e SaaS : 终端 用 户 可 以 直接 使 用 的 应 用 程序 。 这 个 就 太 多 ， 我 们 生活 中 用 到 的 
很 多 软件 都 是 SaaS 服 务 ， 只 要 基于 互联 网 来 提供 的 服务 基本 都 是 SaaS 服 务 ， 
有 的 服务 是 免费 的 ， 比 如 Google Docs， 还 有 更 多 的 是 根据 我 们 购买 的 Plan 和 
使 用 量 付费 ， 比 如 GitHub、 各 种 云 存储 。 


微服 务 介绍 


微服 务 (Microservices) 这 个 词 比较 新 颖 ， 但 是 其 实 这 种 架构 设计 理念 早 就 有 了 。 
微服 务 是 一 种 分 布 式 架 构 设 计 理 念 ， 为 了 推动 细 粒 度 服 务 的 使 用 ， 这 些 服务 要 能 协 
同 工 作 ， 每 个 服务 都 有 自己 的 生命 周期 。 一 个 微服 务 就 是 一 个 独立 的 实体 ， 可 以 独 
立 的 部 署 在 PAAS 平 台 上 ， 也 可 以 作为 一 个 独立 的 进程 在 主机 中 运行 。 服 务 之 间 通 
过 API 访 问 ， 修 改 一 个 服务 不 会 影响 其 它 服 务 。 


要 想 了 解 微 服务 的 详细 内 容 推荐 阅读 《微服 务 设 计 》 (Sam Newman#) ， 我 写 
这 本 书 的 读书 笔记 - 微服 务 设计 读书 笔记 。 


下 文中 会 谈 到 kubernetes 与 微服 务 的 关系 ， 其 中 kubernetes 的 service 天 生 就 适合 于 
微服 务 。 


云 原 生 概 念 介 绍 


下 面 是 Cloud Native 概 念 思维 导 图 
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Kubernetes 与 云 原 生 应 用 概览 


应 用 间 通 过 RESTful API 通 信 


持续 交付 频繁 发 布 、 快 速 交 付 、 快 速 反 馈 、 降 低 发 布 风险 


容器 化 微服 务 的 最 佳 载体 


图 片 - Cloud native 思 维 导 图 





云 原 生 准 确 来 说 是 一 种 文化 ， 更 是 一 种 潮流 ， 它 是 云 计 和 草 的 一 个 必然 导向 。 它 的 意 
义 在 于 让 云 成 为 云 化 战略 成 功 的 基石 ， 而 不 是 阻碍 ， 如 果 业 务 应 用 上 云 之 后 开发 和 
运 维 人 员 比 原先 还 痛苦 ， 成 本 还 高 的 话 ， 这 样 的 云 我 们 宁愿 不 上 。 


自从 云 的 概念 开始 普及 ， 许 多 公司 都 部 署 了 实施 云 化 的 策略 ， 纷 纷 搭建 起 云 平 台 ， 
希望 完成 传统 应 用 到 云端 的 迁移 。 但 是 这 个 过 程 中 会 遇 到 一 些 技术 难题 ， 上 云 以 
后 ， 效 率 并 没有 变 得 奇 高 ， 故 障 也 没有 迅速 定位 。 

为 了 解决 传统 应 用 升级 缓慢 、 架 构 脐 肿 、 不 能 快速 迭代 、 故 障 不 能 快速 定位 、 问 题 
无 法 快速 解决 等 问题 ， 云 原生 这 一 概念 横 空 出 世 。 云 原生 可 以 改进 应 用 开发 的 效 
率 ， 改 变 企业 的 组 织 结构 ， 甚 至 会 在 文化 层面 上 直接 影响 一 个 公司 的 决策 。 

另外 ， 云 原生 也 很 好 地 解释 了 云 上 运行 的 应 用 应 该 具备 什么 样 的 架构 特性 一 一 敏捷 
性 、 可 扩展 性 、 故 障 可 恢复 性 。 


综 上 所 述 ， 云 原生 应 用 应 该 具备 以 下 几 个 关键 词 


e 敏捷 
e "T3 
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e 高 弹性 

e AU 

e 故障 隔离 保护 

e 不 中 断 业 务 持续 更 新 


以 上 特性 也 是 云 原生 区 别 于 传统 云 应 用 的 优势 特点 。 


从 宏观 概念 上 讲 ， 云 原生 是 不 同 思 想 的 集合 ， 集 目前 各 种 热门 技术 之 大 成 ， 具 体 包 
括 如 下 图 所 示 的 几 个 部 分 。 


Kubernetes 与 云 原 生 的 关系 


Kuberentes 可 以 说 是 乘 着 docker 和 微服 务 的 东风 ， 一 经 推出 便 迅 速 蹄 红 ， 它 的 很 多 
设计 思想 都 契合 了 微服 务 和 云 原生 应 用 的 设计 法 则 ， 这 其 中 最 著名 的 就 是 开发 了 
Heroku PaaS 和 平台 的 工程 师 们 总 结 的 Twelve-factor App 了 。 


下 面 我 将 讲解 Kubernetes 设 计时 是 如 何 按照 了 十 二 因素 应 用 法 则 ， 并 给 出 
kubernetes 中 的 应 用 示例 ， 并 附 上 一 句 话 简 短 的 介绍 。 


Kubernetes 介 经 


Kubernetes 是 Google 基 于 Borg 开 源 的 容器 编排 调度 引擎 ， 作 为 CNCF (Cloud 
Native Computing Foundation) 最 重要 的 组 件 之 一 ， 它 的 目标 不 仅仅 是 一 个 编排 系 
统 ， 而 是 提供 一 个 规范 ， 可 以 让 你 来 描述 集群 的 架构 ， 定 义 服务 的 最 终 状态 ， 
kubernetes 可 以 帮 你 将 系统 自动 得 达到 和 维持 在 这 个 状态 。 


更 直 白 的 说 ，Kubernetes 用 户 可 以 通过 编写 一 个 yaml 或 者 json 格 式 的 配置 文件 ， 也 
可 以 通过 工具 /代码 生成 或 直接 请 求 kubernetes API 创 建 应 用 ， 该 配置 文件 中 包含 了 
用 户 想 要 应 用 程序 保持 的 状态 ， 不 论 整个 kubernetes 集 群 中 的 个 别 主 机 发 生 什么 问 
题 ， 都 不 会 影响 应 用 程序 的 状态 ， 你 还 可 以 通过 改变 该 配置 文件 或 请 求 kubernetes 
API 来 改变 应 用 程序 的 状态 。 


12 因 素 应 用 


12 因 素 应 用 提出 已 经 有 几 年 的 时 间 了 ， 每 个 人 对 其 可 能 都 有 自己 的 理解 ， 切 不 可 生 
HARE > 也 不 一 定 所 有 云 原生 应 用 都 必须 符合 这 12 条 法 则 ， 其 中 有 几 条 法 则 可 能 还 
有 点 争议 ， 有 人 对 其 的 解释 和 看 法 不 同 。 


大 家 不 要 孤立 的 来 看 这 每 一 个 因素 ， 将 其 与 自己 软件 开发 流程 联系 起 来 ， 这 12 个 因 
素 大 致 就 是 按照 软件 从 开发 到 交付 的 流程 顺序 来 写 的 。 
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图 片 - 十 二 因素 应 用 


1. 基 准 代码 


每 个 代码 仓库 (repo) 都 生成 docker image 保 存 到 镜像 仓库 中 ， 并 使 用 唯一 的 ID 管 
理 ， 在 Jenkins 中 使 用 编译 时 的 ID o 


2. 依 赖 
显 式 得 声明 代码 中 的 依赖 ， 使 用 软件 包 管 理工 具 声 明 ， 比 如 Go 中 的 Glide。 
3. 配 置 


将 配置 与 代码 分 离 ， 应 用 部 署 到 kubernetes 中 可 以 使 用 容器 的 环境 变量 或 
ConfigMap 挂 载 到 容器 中 。 


4. 后 端 服务 


把 后 端 服务 当 作 附加 资源 ， 实 质 上 是 计算 存储 分 离 和 降低 服务 耦合 ， 分 解 单 体 应 
用 。 


5. 构 建 、 发 布 、 运 行 


严格 分 离 构建 和 运行 ， 每 次 修改 代码 生成 新 的 镜像 ， 重 新 发 布 ， 不 能 直接 修改 运行 
时 的 代码 和 配置 


6. 进 程 
应 用 程序 进程 应 该 是 无 状态 的 ， 这 意味 着 再 次 重启 后 还 可 以 计算 出 原先 的 状态 。 


7. 端 口 绑 定 


在 kubernetes 中 每 个 Pod 都 有 独立 的 |P， 每 个 运 i 用 不 必 关 心 端口 是 
否 重 复 ， 只 需 在 service 中 指定 端口 ， 集 群 内 的 service 通 置 互相 发 现 。 


快速 启动 和 优雅 终止 可 最 大 化 健 半 性 ，Kkuberentes 优 秀 的 Pod 生 存 周期 控制 。 


在 kubernetes 中 可 以 创建 多 个 namespace， 使 用 相同 的 镜像 可 以 很 方便 的 复制 一 套 
环境 出 来 ， 镜 像 的 使 用 可 以 很 方便 的 部 署 一 个 后 端 服务 。 


11. 日 志 

把 日 志 当 作 事 件 流 ， 使 用 stdout 输 出 并 收集 汇聚 起 来 ， 例 如 到 ES 中 统一 查看 。 
12. 管 理 进程 

后 台 管 理 任务 当 作 一 次 性 进程 运行 ， kubect1 exec 进入 容器 内 部 操作 。 


另外 ，Cloud Native Go 这 本 书 的 作者 ，CapitalOne 公 司 的 Kevin Hoffman 在 
TalkingData T11 峰 会 上 的 High Level Cloud Native 的 演讲 中 讲述 了 云 原生 应 用 的 15 
个 因素 ， 在 原先 的 12 因 素 应 用 的 基础 上 又 增加 了 如 下 三 个 因素 : 


API 优 先 


e 服务 间 的 合约 

e 团队 协作 的 规约 
e 文档 化 、 规 范 化 
e RESTful 或 RPC 


监控 


e 实时 监控 远程 应 用 

e 应 用 性 能 监控 (APM) 
e 应 用 健康 监控 

e 系统 日 志 

e 不 建议 在 线 Debug 


认证 授权 


。 不 要 等 最 后 才 去 考虑 应 用 的 安全 性 
e 详细 设计 、 明 确 声 明 、 文 档 化 


e Bearer token ` OAuth ` OIDCZA tE 
e 操作 审计 


详 见 High Level Cloud Native From Kevin Hoffman ° 


Kubernetes 中 的 资源 管理 与 容器 设计 模式 


Kubernetes 通 过 声明 式 配 置 ， 申 正 让 开发 人 员 能 够 理解 应 用 的 状态 ， 并 通过 同一 份 

置 可 以 立马 启动 一 个 一 模 一 样 的 环境 ， 大 大 提高 了 应 用 开发 和 部 署 的 效率 ， 其 中 

een Mn 资源 类 型 可 以 帮助 我 们 定义 应 用 的 运行 状态 ， 并 使 用 资源 配 
置 来 细 粒 度 得 明确 限制 应 用 的 资源 使 用 。 


态 的 成 熟 是 Kubernetes 诞生 的 前 提 ， 在 谈 到 容器 的 设计 模式 之 前 我 们 先 
下 容器 生态 ， 请 看 下 图 : 
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关于 Docker 容器 的 更 多 内 容 请 参考 Docker t & 3X, © 


容器 的 设计 模式 


Kubernetes 提 供 了 多 种 资源 对 象 ， 用 户 可 以 根据 自己 应 用 的 特性 加 以 选择 。 这 些 对 
RA: 


x 
a 名 称 


I Pod ` ReplicaSet ` ReplicationController » Deployment ` StatefulSet ` 
对 DaemonSet ` Job ` CronJob ` HorizontalPodAutoscaling 


iB Node ` Namespace ` Service ` Secret ^ ConfigMap ^ Ingress ^ Label ` 
对 ThirdPartyResource ` ServiceAccount 


fi 
对 
3 


AE 


R 
略 
对 
象 


Volume 、Persistent Volume 


SecurityContext ` ResourceQuota ` LimitRange 


在 Kubernetes 系统 中 ，Kubernetes 对 象 是 持久 化 的 条 目 。Kubernetes 使 用 这 些 
条 目 去 表示 整个 集群 的 状态 。 特 别 地 ， 它 们 描述 了 如 下 信息 : 


e 什么 容器 化 应 用 在 运行 (以 及 在 哪个 Node E) 
e 可 以 被 应 用 使 用 的 资源 
e 关于 应 用 如 何 表 现 的 策略 ， 比 如 重启 策略 、 升 级 策略 ， 以 及 容错 策略 


Kubernetes 对 人 象 是 “目标 性 记录 ”一 一 一旦 创建 对 象 ，Kubernetes 系统 将 持续 工作 
以 确保 对 象 存在 。 通 过 创建 对 象 ， 可 以 有 效 地 告知 Kubernetes 系统 ， 所 需要 的 集 
群 工作 负载 看 起 来 是 什么 样子 的 ， 这 就 是 Kubernetes 集群 的 期 望 状态 。 


详 见 Kubernetes Handbook - Objects。 


资源 限制 与 配额 


两 层 的 资源 限制 与 配置 


e Pod 级别， 最 小 的 资源 调度 单位 
e Namespace 级 别 ， 限 制 资源 配额 和 每 个 Pod 的 资源 使 用 区 间 


请 参考 Kubernetes 中 的 ResourceQuota 和 LimitRange 配 置 资源 限额 


管理 Kubernetes 集 群 


手工 部 署 Kubernetes 是 一 个 很 艰巨 的 活 ， 你 需要 了 解 网 络 配置 、docker 的 安装 与 使 
用 、 镜 像 仓 库 的 构建 、 角 色 证 书 的 创建 、kubernetes 的 基本 原理 和 构成 、 
kubernetes 应 用 程序 的 yaml 文 件 编写 等 。 


我 编写 了 一 本 kubernetes-handbook 可 供 大 家 免费 阅读 ， 该 书记 录 了 本 人 从 零 开 始 
学 习 和 使 用 Kubernetes 的 心路 历程 ， 着 重 于 经 验 分 享 和 总 结 ， 同 时 也 会 有 相关 的 概 
AS RAR > Ar ZAR PK RY Rte VEER o 


#8 X Kubernetes % #7 


使 用 二 进 制 部 署 kubernetes 集群 的 所 有 组 件 和 插件 ， 而 不 是 使 用 kubeadm 等 
自动 化 方式 来 部 署 集群 ， 同 时 开启 了 集群 的 TLS 安 全 认证 ， 这 样 可 以 帮助 我 们 解 系 
统 各 组 件 的 交互 原理 ， 进 而 能 快速 解决 实际 问题 。 详 见 在 CentOS 上 部 署 
Kubernetes 集 群 。 
集群 详情 
e Kubernetes 1.6.0 
e Docker 1.12.5 (使 用 yum 安 装 ) 
e Etcd 3.1.5 
e Flanneld 0.7 vxlan 网 络 
e TLS 认证 通信 (所 有 组 件 ， 如 etcd ` kubernetes master 和 node) 
e RBAC 授权 
e kublet TLS BootStrapping 
e kubedns ` dashboard ` heapster(influxdb ` grafana) ` EFK(elasticsearch ^ 
fluentd ` kibana) 集群 插件 
e 私有 docker 镜 像 仓库 harbor (请 自行 部 署 ，harbor 提 供 离 线 安装 包 ， 直 接 使 用 
docker-compose 启 动 即 可 ) 


. & TLS 3x 44e ALA 
. 创建 kubeconfig 文 件 
创建 高 可 用 etcd 集 群 
安装 kubectl 命 令 行 工 具 
部 署 master 节 点 
X flannel H 46 fF 
部 署 node 节 点 

c kubedns4& 4+ 
x dashboard4& fF 
c heapsterdé fF 
iC REF KA TE 


= OO ANDAR WDND = 
BU 


Q 一 


服务 发 现 与 负载 均衡 


Kubernetes 在 设计 之 初 就 充分 考虑 了 针对 容器 的 服务 发 现 与 负载 均衡 机 制 ， 提 供 了 
Service 资 源 ， 并 通过 kube-proxy 配 合 cloud provider 来 适应 不 同 的 应 用 场景 。 随 着 

kubernetes 用 户 的 激增 ， 用 户 场景 的 不 断 丰 富 ， 又 产生 了 一 些 新 的 负载 均衡 机 制 。 

目前 ，kubernetes 中 的 负载 均衡 大 致 可 以 分 为 以 下 几 种 机 制 ， 每 种 机 制 都 有 其 特定 
的 应 用 场景 : 


e Service : 直接 用 Service 提 供 cluster 内 部 的 负载 均衡 ， 并 借助 cloud provider 提 
供 的 LB 提供 外 部 访问 

e Ingress : 还 是 用 Service 提 供 cluster 内 部 的 负载 均衡 ， 但 是 通过 自 定义 LB 提供 
外 部 访问 

e Service Load Balancer : 把 load balancer 直 接 跑 在 容器 中 ， 实 现 Bare Metal 
的 Service Load Balancer 

e Custom Load Balancer : 自 定 义 负 载 均衡 ， 并 替代 kube-proxy， 一 般 在 物理 
部 署 Kubernetes 时 使 用 ， 方 便 接 入 公司 已 有 的 外 部 服务 


详 见 Kubernetes Handbook - 服务 发 现 与 负载 均衡 。 


持续 集成 与 发 布 











Kubernetes PowerDNS?$$$ filebeat-test.yaml 


apiVersion: extensions/vibetal 
kind: Deployment 
me 





4^ HARBOR" 








Servicename.xxx.xxx:172.168.0.1 


(Update DNS 
































































































d ec 
4p de dp m 
metadata 
€ labels 
k8s-app: filebeat-test 
a| | spect 
. Q With scripts = 
Pull image @call aptVersioni v 
a 6 Kind: Service 
a (6 ©Creating serivce yam! — serivce yaml è j nome: flebent-test 
wv s T app: | filebeat-test 
$ @Push image s speci 
à Jenkins = 
o i 
e P n -— 
S Update ingress | (S)Trigger ] 9 
à mn | GitLab 
y | IM ingress.yaml 
2 | | | 2 apiVersion: extensions/vibetal 
z : uv kind: Ingress 
£z b | 二 metadata: 
3 " Oo name: traefik-ingress 
a | spec 
| 3 rules: 
D host: nginx, talkingdata.com 
a http: 
户 HI E RRA User defined 
_ 1 Y path: / 
9. 2 backend » Service Name 
E o ,| ™ | Resource Request 
= co | pets frontend. talkingdata.com Instance number 
Sri | paths GitURL 
e Ñ | edd a 
9 y servicitine frontend Service type 
= - host: backend. talkingdata. com 
wW 
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图 片 - 使 用 Jenkins 进 行 持续 集成 与 发 布 流 程 图 


应 用 构建 和 发 布 流程 说 明 : 


. 用 户 向 Gitlab 提 交代 码 ， 代 码 中 必须 包含 Dockerfile 

2. 将 代码 提交 到 远程 仓库 

3. 用 户 在 发 布 应 用 时 需要 填写 git 仓 库 地 址 和 分 支 、 服 务 类 型 、 服 务 名 称 、 资 源 数 
量 、 实 例 个 数 ， 确 定 后 触发 Jenkins 自 动 构建 

4. Jenkins 的 CI 流水 线 自动 编译 代码 并 打包 成 docker 镜 像 推送 到 Harbor 镜 像 仓库 

5. Jenkins 的 CI 流水 线 中 包括 了 自 定 义 脚 本 ， juin 已 准备 好 的 kubernetes 的 
YAML 模 板 ， 将 其 中 的 变量 替换 成 用 户 输入 的 选 

6. 生成 应 用 的 kubernetes YAML 配 置 文件 

7. 更 新 Ingress 的 配置 ， 根 据 新 部 署 的 应 用 的 名 称 ， 在 ingress 的 配置 文件 中 增加 
一 条 路 由 信息 

8. 更 新 PowerDNS ， ee DNS 记录 ，IP 地 址 是 边缘 节点 的 I|P 地 址 。 关 
于 边缘 节点 ， 请 查看 边缘 节点 配置 

9. Meis Minn i) ， 部 署 应 用 


日 志 收 集 与 监控 


基于 现 有 的 ELK 日 志 收 集 方案 ， 稍 作 改 造 ， 选 用 filebeat 来 收集 日 志 ， 可 以 作为 
sidecar 的 形式 跟 应 用 运行 在 同一 个 Pod 中 ， 比 较 轻 量 级 消耗 资源 比较 少 。 








Suberneres filebeat-test.yaml 









- Log 
I Collection 


apiVersion: extensions/vibetal 


spec: 
replicas: 3 


d Deploy 
docker 


Push 


template: 
9 g& metadata: ~ 
12 spec: 
13 containers: 
14 图 — image: filebeat:5.4.0~ 
21 图 — image: docker-test:Build 8- 
28 volumes: 
29 - name: app-logs 
30 emptyDir: {} 
31 - name: filebeat-config " 
32 configMap: Define 
33 name: filebeat-config I4———— — 










> elastic 


| Show 


区 kibana 


| 


Doc: filebeat-docker-test/log/AVzs1 QzKdPYTkmBgkats 


Table JSON 





a 
Y 
ER 
v 
3 
o 
v 
v 
= 
Y 
S 
L 
Y 
a 
3 
M 


35 — apiVersion: vl 
36 kind: ConfigMap 






37 s metadata: ~ 
39 data: 
40 filebeat.yml: | 






41 filebeat. prospectors: 
42 =- input type: log 

43 paths: 

44 - "/log/x" 








45 - "/log/usermange/common/4" 
46 output.elasticsearch: 

47 hosts: ["172.23.5.255:9200"] 
48 username: "elastic" 

49 password: "changeme" 


50 index: "filebeat-test" Wacth 













@timestamp ^ June 28th 2017, 11:53:19.425 
t Lid AVzslQzKdPYTkmBgkats 
t index filebeat-docker-test 
4 .score 
t .type log 
t beat.hostname filebeat-test-2365467882-4zwx8 


t beat.name filebeat-test-2365467882-4zwx8 


PO OMRON > | 





t beat.version 5.4.0 
t input type log 


t message 2017-06-02 15:14:48.592 [net.sf.ehcache.CacheManager614a616] INFO net.sf.ehcache.util.UpdateChecker-New update(s) found: 2.6.5 [http://www.terracotta.org/confluenc 
e/display/release/Release«Notes«Ehcache«Core*2.6]. Please check http://ehcache.org for the latest version. 


# offset 272 


t source /109/2017. 06. 02. stderrout.1og 


t type log 
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详 见 Kubernetes Handbook - 应 用 日 志 收 集 。 


安全 性 与 权限 管 


LU qm 租户 的 云 平台 ， 因 ss 2. 户 的 权限 加 以 限制 ， 对 用 户 空间 
进行 隔离 。Kubernetes 中 的 隔离 主要 包括 这 


网 络 隔离 : 需要 使 用 网 络 插件 ， 比 如 calico。 


e 资源 隔离 : kubernetes 原 生 支 持 资源 隔离 ，pod 就 是 资源 就 是 隔离 和 调度 的 最 
小 单位 ， 同 时 使 用 namespace 限 制 用 户 空 间 和 资源 限额 。 
e 身份 隔离 : 使 用 RBAC- 基 于 角色 的 访问 控制 ， 多 租户 的 身份 认证 和 权限 控制 。 


如 何 开发 Kubernetes 原 生 应 用 步骤 介绍 


当 我 们 有 了 一 个 kubernetes 集 群 后 ， 如 何在 上 面 开发 和 部 署 应 用 ， 应 该 遵循 怎样 的 
流程 ?下 面 我 将 展示 如 何 使 用 go 语言 开发 和 部 署 一 个 kubernetes native 应 用 ， 使 用 
wercker 进 行 持续 集成 与 持续 发 布 ， 我 将 以 一 个 很 简单 的 前 后 端 访问 ， 获 取 伪 造 数 
据 并 展示 的 例子 来 说 明 。 


云 原 生 应 用 开发 示例 


我 们 将 按照 如 下 步骤 来 开发 部 署 一 个 Kubernetes 原 生 应 用 并 将 它 部 署 到 kubernetes 
集群 上 开放 给 集群 外 访问 : 


1. 服务 API 的 定义 

2. 使 用 Go 语言 开发 Kubernetes 原 生 应 用 

3. 一 个 持续 构建 与 发 布 工具 与 环境 

4. 使 用 traefik 和 VIP 做 边缘 节点 提供 外 部 访问 路 由 


我 写 了 两 个 示例 用 于 演示 ， 开 发 部 署 一 个 伪造 的 metric 并 显示 在 web 页 面 上 ， 包 
括 两 个 service : 


e k8s-app-monitor-test : 生成 模拟 的 监控 数据 ， 发 送 http 请 求 ， 获 取 json 返 回 值 
e K8s-app-monitor-agent : 获取 监控 数据 并 绘图 ， 访 问 浏 览 器 获取 图 表 


A LAPI APIS 74 


使 用 API blueprint 格式 ， 定 义 AP| 文 档 ， 格 式 类 似 于 markdown， 再 使 用 aglio 生 
成 HTML 文 档 。 


Kubernetes 与 云 原 生 应 用 概览 


Overview 


Metrics 


Resource Group 
List All Metric + 


Get the specific application... + 


http://localhost:3000/ 


] 


Kubernetes app monitoring test 


This is a simple application to test the application monitoring in kubernetes. For the rules used as a reference 
when building this application, see The Rules of Go 


Metrics 


The application only has one monitoring metric now. 


Resource Group 


METRICS COLLECTION 


The metric collection represents the status of the application. 


LE /metrics List All Metric 


Get the application's metric now. 
Example URI 


GET http://localhost:3000//metrics 
Response 200 Show 


GET SPECIFIC APPLICATION METRIC 


Get the specific application's metric. 
LE /metrics/{appname} Get the specific application metric 


Example URI 


GET http://localhost:3000//metrics/"Gateway_quota_request" 
URI Parameters Hide 


appname string (required) Example: "Gateway_quota_request’ 


Response 200 Show 


Response 404 Show 


Generated by aglio on 18 Jul 2017 


图 片 - AP/ 文 档 


详 见 : 如 何 开发 部 署 kubernetes native 应 用 。 


如 何 迁 移 到 云 原 生 应 用 架构 


Pivotal 是 云 原生 应 用 的 提出 者 ， 并 推出 了 Pivotal Cloud Foundry 云 原生 应 用 平台 
和 Spring 开源 Java 开发 框架 ， 成 为 云 原 生 应 用 架构 中 先驱 者 和 探 路 者 。 


CD 
Ol 


原 书 作 于 2015 年 ， 其 中 的 示例 主要 针对 Java 应 用 ， 实 际 上 也 适用 于 任何 应 用 类 

型 ， 云 原生 应 用 架构 适用 于 异 构 语 言 的 程序 开发 ， 不 仅仅 是 针对 Java 语言 的 程序 
开发 。 截 止 到 本 人 翻译 本 书 时 ， 云 原生 应 用 生态 系统 已 经 初 具 规 模 ，CNCF 成 员 不 
断 发 展 壮 大 ， 基 于 Cloud Native 的 创业 公司 不 断 涌现 ，kubernetes 引领 容器 编排 
潮流 ， 和 Service Mesh 技术 (如 Linkerd fe Istio) 的 出 现 ，Go 语言 的 兴起 ( 
考 另 一 本 书 Cloud Native Go) 等 为 我 们 将 应 用 迁移 到 云 原生 架构 的 提供 了 更 多 的 
方案 选择 。 


迁移 到 云 原生 应 用 架构 指南 


指出 了 迁移 到 云 原生 应 用 架构 需要 做 出 的 企业 文化 、 组 织 架构 和 技术 变革 ， 并 给 出 
了 迁移 指南 。 


主要 讨论 的 应 用 程序 架构 包括 : 


e 十 二 因素 应 用 程序 : 云 原生 应 用 程序 架构 模式 的 集合 

e 微服 务 : 独立 部 署 的 服务 ， 只 做 一 件 事 情 

e 自助 服务 的 敏捷 基础 设施 : 快速 ， 可 重复 和 一 致 地 提供 应 用 环境 和 后 台 服 务 的 
平台 

e. 基于 API 的 协作 : 发 布 和 版 本 化 的 API， 允 许 在 云 原生 应 用 程序 架构 中 的 服务 之 
间 进 行 交 互 

o WEH : 根据 压力 变 强 的 系统 


详 见 : 迁移 到 云 原生 应 用 架构 


ResourceManager 
YARN 

Decomposing services 
spark client 

Building docker images my-docker-repo/hadoop:2.6.0:v1 

Migrating hadoop 
Configuration files 
YARN to kubernetes 
ConfigMaps 
Kubernetes YAML files Kubernetes resource objects 
hadoop-bootstrap.sh 
Bootstrap scripts 
Source https://github.com/rootsongjc/kubernetes-handbook spark-bootstrap.sh 





步骤 说 明 : 


.将 原 有 应 用 拆 解 为 服务 

. 容器 化 、 制 作 镜 像 
.准备 应 用 配置 文件 

准备 kubernetes YAML 文 件 
.编写 bootstarp 脚 本 

. 创建 ConfigMaps 


DARON 





详 见 : 迁移 传统 应 用 到 Kubernetes 步 又 详解 一 一 尺 Hadoop YARN X 45] » 


Service mesh 基 本 原理 和 示例 介绍 


Service mesh 现 在 一 般 被 翻译 作 服务 网 格 ， 目 前 主流 的 Service mesh 有 如 下 两 款 : 


e lstio : IBM、Google、Lyft 共 同 开 源 ， 详 细 文 档 见 |stio 官 方 文档 中 文 版 
e Linkerd : 原 Twitter 工 程 师 开发 ， 现 为 CNCF 中 的 项 目 之 一 


什么 是 Service mesh 


如 果 用 一 句 话 来 解释 什么 是 Service Mesh， 可 以 将 它 比 作 是 应 用 程序 或 者 说 微服 务 
间 的 TCP/IP， 负 责 服务 之 间 的 网 络 调用 、 限 流 、 熔 断 和 监控 。 对 于 编写 应 用 程序 
来 说 一 般 无 须 关 心 TCP/IP 这 一 层 (比如 通过 HTTP 协议 的 RESTful gH) ， 同 样 
使 用 Service Mesh 也 就 无 须 关系 服务 之 间 的 那些 原来 是 通过 应 用 程序 或 者 其 他 框 
架 实现 的 事情 ， 比 如 Spring Cloud ` OSS ， 现 在 只 要 交 给 Service Mesh 就 可 以 


T a 
Service Mesh’s 
Control Plane 
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图 片 - service mesh 架 构图 


详 见 什么 是 service mesh - jimmysong.io ° 


Service mesh 使 用 指南 


A Service mesh 各 有 千秋 ， 我 分 别 写 了 他 们 的 使 用 案例 指南 : 


o 微服 务 管理 框架 service mesh 一 一 Linkerd 安 装 试用 笔记 
e 微服 务 管理 框架 service mesh 一 一 lstio 安 装 试用 笔记 


更 多 关于 Service Mesh 的 内 容 请 访问 Service Mesh 中 文 网 。 
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Kubernetes 作 为 云 原 生计 算 的 基本 组 件 之 一 ， 开 源 2 年 时 间 以 来 热度 与 日 俱 增 ， 它 
可 以 跟 我 们 的 生产 结合 ， 控 出 很 多 火花 ， 比 如 FaaS 和 Serverless 类 应 用 ， 都 很 适合 
运行 在 kubernetes 上 » 


关于 Cloud Native 开 源 软 件 生态 请 参考 Awesome Cloud Native - jimmysong.io ° 


DevOps 


下 面 是 社区 中 kubernetes 开 源 爱 好 者 的 分 享 内 容 ， 我 觉得 是 对 kubernetes 在 
DevOps 中 应 用 的 很 好 的 形式 值得 大 家 借鉴 。 


真正 践 行 DevOps， 让 开发 人 员 在 掌握 自己 的 开发 和 测试 环境 ， 让 环境 一 致 ， 让 开 
发 效率 提升 ， 让 和 运 维 没 有 堆积 如 山 的 tickets， 让 监控 更 加 精准 ， 从 kubernetes 平 台 


1. 根据 环境 (比如 开发 、 测 试 、 生 产 ) 划分 namespace ， 也 可 以 根据 项 目 来 划 
分 

2. 再 为 每 个 用 户 划 分 一 个 namespace 、 创 建 一 
个 serviceaccount 和 kubeconfig 文件 ， 不 同 namespace 间 的 资源 隔 
离 ， 目 前 不 隔离 网 络 ， 不 同 namespace 间 的 服务 可 以 互相 访问 

3. 创建 yaml 模 板 ， 降 低 编写 kubernetes yaml 文 件 编写 难度 

4. 在 kubectl 命令 上 再 封装 一 层 ， 增 加 用 户 身份 设置 和 环境 初始 化 操作 ， 简 
化 kubectl 命令 和 常用 功能 

5. 管理 员 通 过 dashboard 查 看 不 同 namespace 的 状态 ， 也 可 以 使 用 它 来 使 操作 
更 便捷 

6. 所 有 应 用 的 日 志 统 一 收集 到 ElasticSearch 中 ， 统 一 日 志 访 问 入 口 

7. 可 以 通过 Grafana 查 看 所 有 namespace 中 的 应 用 的 状态 和 kubernetes 集 群 本 身 
的 状态 

8. 需要 持久 化 的 数据 保存 在 分 布 式 存储 中 ， 例 如 GlusterFS 或 Ceph 中 


使 用 Kibana 查 看 日 志 


日 志 字段 中 包括 了 应 用 的 标签 、 容 器 名 称 、 主 机 名 称 、 宿 主机 名 称 、IP 地 址 、 时 
间 、 
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使 用 Grafana 查 看 应 用 状态 


it: 感谢 【K8SCloud Native 实战 群 】 苯 贵 的 黄金 会 员 小 刚 同 学 提供 下 面 的 


Grafana 监 控 图 
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Ak - Grafana 界 面 示 意图 1 


Kubernetes 集 群 全 局 监控 图 1 


该 监控 图 可 以 看 到 集群 硬件 使 用 情况 。 


BB node 分 布 式 节点 


集群 cpu 使 用 [总 all-node-cpu -sum 
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Kubernetes 全 局 监控 图 2 
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集群 存储 文件 系统 总 使 用 
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图 片 - Grafana 界 面 示 意图 2 


工作 节点 内 存 使 用 并 


监控 可 以 看 到 单个 用 户 的 namespace 下 的 所 有 资源 的 使 用 情况 。 


ZoomOut > OUas 
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Spark on Kubernetes 
TL;DR 


Spark/*: Æ %4#standalone ` mesos#? YARN 3t 7$ 38/2. » I C, & 44 Kubernetes/$. +% 
Eo di», | à 


A tT 21% | spark on kubernetes 


4& A kubernetes/$ + 7 € 8 spark on kubernetes € *1/$ 2 49 spark on yarn 和 yarn on 
docker 的 改变 是 单 命 性 的 ， 主 要 表现 在 以 下 几 点 : 


1. Kubernetes 原 生 调度 : 不 再 需要 二 层 调度 ， 直 接 使 用 kubernetes 的 资源 调度 
功能 ， 跟 其 他 应 用 共用 整个 kubernetes 管 理 的 资源 池 ; 

2. 资源 隔离 ， 粒 度 更 细 : 原先 yarn 中 的 queue 在 spark on kubernetes 中 已 不 存 
在 ， 取 而 代 之 的 是 kubernetes 中 原生 的 namespace， 可 以 为 每 个 用 户 分 别 指定 
一 个 namespace， 限 制 用 户 的 资源 quota ; 

3. 细 粒 度 的 资源 分 配 : 可 以 给 每 个 spark 任 务 指定 资源 限制 ， 实 际 指定 多 少 资源 
就 使 用 多 少 资源 ， 因 为 没有 了 像 yarn 那 样 的 二 层 调 度 (园地 式 的 ) ， 所 以 可 以 
更 高 效 和 细 粒 度 的 使 用 资源 ; 


监控 的 变革 : 因为 做 到 了 细 粒 度 的 资源 分 配 ， 所 以 可 以 对 用 户 提交 的 每 一 个 任 
务 做 到 资源 使 用 的 监控 ， 从 而 判断 用 户 的 资源 使 用 情况 ， 所 有 的 metric 都 记录 
在 数据 库 中 ， 甚 至 可 以 为 每 个 用 户 的 每 次 任务 提交 计量 ; 


5. 日 志 的 变革 : 用 户 不 再 通过 am Wb OR ne 而 是 通过 pod 的 


log 来 查看 ， 可 将 所 有 的 kuberentes 中 的 应 用 的 日 志 等 同 看 待 收集 起 来 ， 然 后 可 
以 根据 标签 查看 对 应 应 用 的 日 志 ; 


如 何 提 交 任 务 


仍然 使 用 spark-submit 提交 spark 任 务 ， 可 以 直接 指定 kubernetes API server 地 
址 ， 下 面 的 命令 提交 本 地 jar 包 到 kubernetes 集 群 上 运行 ， 同 时 指定 了 运行 任务 的 用 


户 


、 提 交 命 名 的 ^ 户 、 运 行 的 excutor 实 例 数 、driver 和 executor 的 资源 限制 、 使 用 


的 spark 版 本 等 信息 


详细 使 用 说 明 见 Apache Spark on Kubernetes 用 户 指南 - jimmysong.io ° 


./Spark-submit \ 


--deploy-mode cluster \ 

--class com.talkingdata.alluxio.hadooptest \ 

--master k8s://https://172.20.0.113:6443 \ 
--kubernetes-namespace spark-cluster \ 

--conf spark.kubernetes.driverEnv.SPARK_USER=hadoop \ 

--conf spark.kubernetes.driverEnv.HADOOP_USER_NAME=hadoop \ 
--conf spark.executorEnv.HADOOP_USER_NAME=hadoop \ 

--conf spark.executorEnv.SPARK_USER=hadoop \ 

--conf spark.kubernetes.authenticate.driver .serviceAccountName= 


spark \ 


--conf spark.driver.memory=100G \ 

--conf spark.executor.memory=10G \ 

--conf spark.driver.cores=30 \ 

--conf spark.executor.cores=2 \ 

--conf spark.driver.maxResultSize-10240m \ 

--conf spark.kubernetes.driver.limit.cores-32 \ 
--conf spark.kubernetes.executor.limit.cores-3 \ 
--conf spark.kubernetes.executor.memoryOverhead-2g \ 
--conf spark.executor.instances=5 \ 

--conf spark.app.name=spark-pi \ 

--conf spark.kubernetes.driver.docker.image-harbor-001.jimmyso 


ng.io/library/spark-driver:v2.1.0-kubernetes-0.3.1-1 \ 


--conf spark.kubernetes.executor.docker.image-harbor-001.jimmy 


song.io/library/spark-executor:v2.1.0-kubernetes-0.3.1-1 \ 


--conf spark.kubernetes.initcontainer.docker.image-harbor-001. 


jimmysong.io/library/spark-init:v2.1.0-kubernetes-0.3.1-1 \ 


--conf spark.kubernetes.resourceStagingServer.uri-http://172.2 


0.0.114:31000 \ 
~/Downloads/tendcloud_2.10-1.0.jar 











监控 


下 图 是 从 Kubernetes dashboard 上 看 到 的 spark-cluster 这 个 namespace 上 运行 的 应 


用 情况 。 
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下 图 是 从 Grafana 监 控 页 面 上 查看 到 的 某 个 executor 资 源 占用 情 ， 
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8 Pods. € A % € zoomout > © Last 5 minutes 


namespace — dev- podname ^ auto-model-worker-1270771004-6d90p ~ 


Individual CPU Usage: dev auto-model-worker-1270771004-6d90p 
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dev auto-model-worker-1270771004-6d90p worker 一 Limit dev auto-model-worker-1270771004-6d90p worker 一 Request dev auto-model-worker-1270771004-6d90p worker 


Individual Memory Usage: dev auto-model-worker-1270771004-6d90p 
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Usage dev auto-model-worker-1270771004-6d90p worker — Limit dev auto-model-worker-1270771004-6d90p worker — Request dev auto-model-worker-1270771004-6d90p worker — Working Set dev auto-model-worker-1270771004-6d90p worker 
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Filesystem Usage: dev auto-model-worker-1270771004-6d90p 
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云 原 生 应 用 之 路 一 从 Kubernetes 到 Cloud 
Native 


从 Kubernetes 到 Cloud Native 一 一 云 原 生 应 用 之 路 ， 这 是 我 最 近 在 
ArchSummit2017 北 京 站 和 数 人 云 &TalkingData 合 办 的 Service Mesh is coming 
meetup 中 分 享 的 话题 。 


本 文 简要 介绍 了 容器 技术 发 展 的 路 径 ， 为 何 Kubernetes 的 出 现 是 容器 技术 发 展 到 这 
一 步 的 必然 选择 ， 而 为 何 Kuberentes 又 将 成 为 云 原生 应 用 的 基石 。 


我 的 分 享 按照 这 样 的 主线 展开 : 容器 ->Kubernetes-> 微 服务 ->Cloud Native ( 云 原 
生 ) ->Service Mesh (服务 网 格 ) -> 使 用 场景 ->Open Source (开源 ) ° 
vg, 


+ n 


ii 


容器 一 一 Cloud Native) X6 


云 原 生 应 用 之 路 一 “从 Kubernetes 到 Cloud Native 





图 片 - Cloud Native 容 器 实验 室 


容器 最 初 是 通过 开发 者 工具 而 流行 ， 可 以 使 用 它 来 做 隔离 的 开发 测试 环境 和 持续 集 
成 环境 ， 这 些 都 是 因为 容器 轻 量 级 ， 钨 于 配置 和 使 用 带 来 的 优势 ，docker 和 docker- 
compose 这 样 的 工具 极 大 的 方便 的 了 应 用 开发 环境 的 搭建 ， 开 发 者 就 像 是 化 学 家 一 
样 在 其 中 小 心 翼 翼 的 进行 各 种 调试 和 开发 。 


随 着 容器 的 在 开发 者 中 的 普及 ， 已 经 大 家 对 Cl 流程 的 熟悉 ， 容 器 周边 的 各 种 工具 莲 
勃发 展 ， 全 然 形 成 了 一 个 小 生态 ， 在 2016 年 达到 顶峰 ， 下 面 这 张 是 我 画 的 容器 生态 
图 : 
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该 生态 涵盖 了 容器 应 用 中 从 镜像 仓库 、 服 务 编排 、 安 全 管理 、 持 续集 成 与 发 布 、 存 
储 和 网 络 管理 等 各 个 方面 ， 随 着 在 单 主 机 中 运行 容器 的 成 熟 ， 集 群 管理 和 容器 编排 
成 为 容器 技术 亚 待 解决 的 问题 。 壁 如 化 学 家 在 实验 室 中 研究 出 来 的 新 产品 ， 如 何 推 
向 市 场 ， 进 行 大 规模 生产 ， 成 了 新 的 议题 。 


为 什么 使 用 Kubernetes 


Kubernetes 











图 片 - Cloud Nativex # 


Kubernetes 是 容器 编排 系统 的 事实 标准 


在 单机 上 运行 容器 ， 无 法 发 挥 它 的 最 大 效能 ， 只 有 形成 集群 ， 才 能 最 大 程度 发 挥 容 
器 的 良好 隔离 、 资 源 分 配 与 编排 管理 的 优势 ， 而 对 于 容器 的 编排 管理 ，Swarm ` 
Mesos 和 Kubernetes 的 大 战 已 经 基本 宣告 结束 ，kubernetes 成 为 了 无 可 争议 的 赢 

家 。 

下 面 这 张 图 是 Kubernetes 的 架构 图 (图 片 来自 网 络 ) ， 其 中 显示 了 组 件 之 间 交 互 的 
4 Y CNI ^ CRI ` OCIS > xx Xd Kubernetes 5 X: RRA F oo AER o 257 PR A E 
TI 427% > £ft-KubernetesZ HLA KA 35 z 8 LE 8 AMR E LIS RE A © 


Kubernetes high-level component architecture 
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| Hardware | | Hardware | | Hardware | 


Node 1 Node 2 Node 3 











图 片 - Kuberentes?& 4j 


随 着 Kubernetes 的 日 趋 成 熟 ，“Kubernetes is becoming boring”， 基 于 该 “操作 系 
统 " 之 上 构建 的 适用 于 不 同 场景 的 应 用 将 成 为 新 的 发 展 方向 ， 就 像 我 们 将 石油 开采 出 
来 后 ， 提 炼 出 汽油 、 桨 油 、 源 青 等 等 ， 所 有 的 材料 都 将 找到 自己 的 用 途 ， 
Kubernetes 也 是 ， 毕 竟 我 们 谁 也 不 是 为 了 部 署 和 管理 容器 而 用 Kubernetes， 承 载 其 
上 的 应 用 才 是 价值 之 所 在 。 


云 原 生 的 核心 目标 





图 片 - Cloud Native Core target 


云 已 经 可 以 为 我 们 提供 稳定 可 以 唾 手 可 得 的 基础 设施 ， 但 是 业务 上 云 成 了 一 个 难 
题 ，Kubernetes 的 出 现 与 其 说 是 从 最 初 的 容器 编排 解决 方案 ， 倒 不 如 说 是 为 了 解决 
应 用 上 云 ( 即 云 原 生 应 用 ) 这 个 难题 。 


包括 微服 务 和 FaaS/Serverless 架 构 ， 都 可 以 作为 云 原 生 应 用 的 架构 。 


Function-as-a-Service Landscape 44 Redpoint 
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EH - FaaS Landscape 


但 就 2017 年 为 止 ，kubernetes 的 主要 使 用 场景 也 主要 作为 应 用 开发 测试 环境 、 
CI/CD 和 运行 Web 应 用 这 几 个 领域 ， 如 下 图 TheNewStack 的 Kubernetes 生 态 状况 调 
查 报 告 所 示 。 


云 原 生 应 用 之 路 一 “从 Kubernetes 到 Cloud Native 


Workloads Running on Kubernetes 


App development (e.g., IDE, CI/CD, platform, test) 
Web services and ecommerce 
Industry-specific applications 


Website hosting and web presence 










Database and data warehousing These values are low. 
Infrastructure services Revolutionary architectures 
(e.g., public/private cloud services) in modern computing 
SaaS delivery have yet to revolutionize 
; the containerization space. 
Mobile applications and services 
Business applications (e.g., ERP, CRM, email) 
Big data analytics, mining (e.g., Hadoop, Spark) 
A category vendors said 
Other line of business (LOB) applications was being transformed by 


Media streaming and content delivery Kubernetes is at the bottom. 


Research computing (e.g., HPC, HTC) 


% of Respondents Running Each Workload 
(select all that applies) 


Source: The New Stack 2017 Kubernetes User Experience Survey. 
Q. What types of workloads does your enterprise or organization run on Kubernetes? n=235. THENEWSTACK 


图 片 - Workloads running on Kubernetes 


另外 基于 Kubernetes 的 构建 PaaS 平 台 和 Serverless 也 处 于 爆发 的 准备 的 阶段 ， 如 下 
图 中 Gartner 的 报告 中 所 示 : 
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原生 应 用 之 路 从 Kubernetes 到 Cloud Native 





Gartner Hype Cycle for Emerging Technologies, 2017 


Plateau will be reached in: 


Expectations 





As of July 2017 


' : Poak of 1 B Plat f 
specs i inflated " m da Slope of Enlightenment P Age - 
rigger Expectations Disillusionment roductivity 





Time 


gartner.com/SmarterWithGartner 


Source: Gartner (July 2017) Gartner 
e 


© 2017 Gartner, Inc. and/or its affiliates. All rights reserved. 


E A - Gartneri AIR A38 # A 2017 


当前 各 大 公有 云 如 Google GKE、 微 软 Azure ACS ^ 3E E 3&EKS (20184. EA). ` 
VmWare ` Pivotal ` Ez ` PIE xA AME TKuberentes/R 2- » 


微服 务 
微服 务 Cloud Native 的 应 用 架构 。 





下 图 是 Bilgin lbryam 给 出 的 微服 务 中 应 该 关心 的 主题 ， 图 片 来 自 RedHat 


Developers ° 


55 









Scheduling 
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Tracing 













Centralized 
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Service 
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图 片 - Microservices concerns 


微服 务 带 给 我 们 很 多 开发 和 部 署 上 的 灵活 性 和 技术 多 样 性 ， 但 是 也 增加 了 服务 调用 
的 开销 、 分 布 式 系统 管理 、 调 试 与 服务 治理 方面 的 难题 。 


当前 最 成 熟 最 完整 的 微服 务 框架 可 以 说 非 Spring 英 属 ， 而 Spring 又 仅 限 于 Java 语 言 
开发 ， 其 架构 本 身 又 跟 Kubernetes 存 在 很 多 重合 的 部 分 ， 如 何 探索 将 Kubernetes 作 
为 微服 务 架 构 平 台 就 成 为 一 个 热点 话题 。 


就 拿 微 服务 中 最 基础 的 服务 注册 发 现 功 能 来 说 ， 其 方式 分 为 客户 端 服务 发 现 和 服务 
端 服 务 发 现 两 种 ，Java 应 用 中 常用 的 方式 是 使 用 Eureka 和 Ribbon 做 服务 注册 发 现 
和 负载 均衡 ， 这 属于 客户 端 服务 发 现 ， 而 在 Kubernetes 中 则 可 以 使 用 DNS、 
Service 和 lngress 来 实现 ， 不 需要 修改 应 用 代码 ， 直 接 从 网 络 层 面 来 实现 。 


M. Kubernetes £l Cloud Native 





Service Discovery in Microservices 


Client-side Service Discovery Server-side Service Discovery 







Consume the service 





Request to consume the service 


Ribbon 


Router/Load Balancer 


Request for service address Lo ATI e Infrastructure provided 


Kubernetes/SkyDNS 
Ingress LB 

Traefik 
PowerDNS 





Eureka 


Register 


Forward 








© Jimmy Song https://github.com/rootsongjc/kubernetes-handbook 


图 片 - 两 种 服务 发 现 方式 





Cloud Native 


通 向 云 原生 的 云梯 





DevOps 


云 原生 应 用 之 路 





| Cloud Native 





图 片 - Cloud Native Pipeline 


CNCF ( 云 原生 计算 基金 会 ) 给 出 了 云 原 生 应 用 的 三 大 特征 : 


e 容器 化 包装 : 软件 应 用 的 进程 应 该 包装 在 容器 中 独立 运行 。 
动态 管理 a 系统 来 动态 的 管理 和 调度 
e 微服 务 化 : 明确 服务 间 的 依赖 ， 互 相 解 斐 。 


下 图 是 我 整理 的 关于 云 原生 所 需要 的 能 力 和 特征 。 
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云 原 生 应 用 之 路 一 “从 Kubernetes 到 Cloud Native 


应 用 间 通 过 RESTful API 通 信 


这 部 和 到 生产 于 


图 片 - Cloud Native Features 


CNCF 所 托管 的 应 用 (目前 已 达 12 个 ) ， 即 朝 着 这 个 目标 发 展 ， 其 公布 的 Cloud 
Native Landscape， 给 出 了 云 原生 生态 的 参考 体系 。 


云 原 生 应 用 之 路 一 “从 Kubernetes 到 Cloud Native 


Cloud Native Landscape 
v7.0 Application 
Database & Data Analytics Definition 


Platforms RS 


App Definition 


Orchestration & 
Management 


H 


g 
tiru 


Runtime 


Host Management / Tooling Infrastructure Automation 


Provisioning 
i$ie i; 





9 $5 oO e Md This landscape is intended as a map through the CLOUD NATIVE 
EDS Tes TBM Cloud Ababa [5 previously uncharted terrain of cloud native tech- COMPUTING FOUNDATION 
nologies. There are many routes to deploying a 
H cloud native application, with CNCF Projects 2 
github. Sepre ee representing a particularly well-traveled path. (44 Redpoint Amplify 





图 片 - Cloud Native Landscape v1.0 


使 用 Kubernetes 构 建 云 原生 应 用 
我 们 都 是 知道 Heroku 推 出 了 适用 于 PaaS 的 12 factor app 的 规范 ， 包 括 如 下 要 素 : 


基准 代码 

依赖 管理 

配置 

后 端 服务 

构建 ， 发 布 ， 运 行 
无 状态 进程 
端口 绑 定 

并 发 

9. HAH 

10. 开发 环境 与 线 上 环境 等 价 
11. 日 志 作 为 事件 流 
12. 管理 进程 


po N O gro IM I 


另外 还 有 补充 的 三 点 : 


e API 声 明 管 理 
e 认证 和 授权 


60 


监控 与 告 
如 果 落 实 的 具体 的 工具 ， 请 看 下 图 ， 使 用 Kubernetes 构 建 云 原生 架构 : 











PG Building Cloud Native Architecture 
with Kubernetes 


source https://jimmysong.io 





NER 


docker MySQL: MySQL: 








图 片 Building a Cloud Native Architecture with Kubernetes followed 12 factor app 


合 这 12 因 素 对 开发 或 者 改造 后 的 应 用 适合 部 署 到 Kubernetes 之 上 ， 基 本 流程 如 下 
Bs : 


MKubernetes £] Cloud Native 


Building docker images 
App Configuration files 
Creating kubernetes | App Configuration fles | 





<-i o M> 
Z ]3. £ M 用 X 


native app 





ConfigMaps (Optional) 


Kubernetes YAML files 


Bootstrap scripts (Optional) 


B - Creating Kubernetes native app 


迁移 到 云 架构 

迁移 到 云端 架构 ， 相 对 单 体 架 构 来 说 会 带 来 很 多 挑战 。 比 如 自动 的 持续 集成 与 发 
布 、 服 务 监控 的 变革 、 服 务 暴 露 、 权 限 的 管控 等 。 这 些 具体 细节 请 参 

考 Kubernetes-handbook 中 的 说 明 : https://jimmysong.io/kubernetes-handbook ， 
在 此 就 不 细节 展开 ， 另 外 推荐 一 本 我 翻译 的 由 Pivotal 出 品 的 电子 书 一 一 Migrating to 
Cloud Native Application Architectures ， 地 址 : https://jimmysong.io/migrating-to- 
cloud-native-application-architectures/ ° 


Service Mesh 


Services for show, meshes for a pro. 


Services for show; 


Pd 


meshes for a pro. 


Nw v 


图 片 - Service Mesh? 4% R slogan 





Kubernetes 中 的 应 用 将 作为 微服 务 运行 ， 但 是 Kuberentes 本 身 并 没有 给 出 微服 务 治 
理 的 解决 方案 ， 比 如 服务 的 限 流 、 熔 断 、 良 好 的 灰 度 发 布 支持 等 。 


Service mesh 可 以 用 来 做 什么 


e Traffic Management : API 网 关 
e Observability : 服务 调用 和 性 能 分 析 
e Policy Enforcment : 控制 服务 访问 策略 
e Service Identity and Security : 安全 保护 
Service mesh 的 特点 
e 专用 的 基础 设施 层 
e 轻 量 级 高 性 能 网 络 代理 
e 提供 安全 的 、 快 速 的 、 可 靠 地 服务 间 通 讯 
e 扩展 kubernetes 的 应 用 负载 均衡 机 制 ， 实 现 灰 度 发 布 
e 完全 解 耦 于 应 用 ， 应 用 可 以 无 感知 ， 加 速 应 用 的 微服 务 和 云 原生 转型 


使 用 Service Mesh 将 可 以 有 效 的 治理 Kuberentes 中 运行 的 服务 ， 当 前 开源 的 
Service Mesh 有 : 


e Linkderd : https:Wlinkerd.io， 由 最 早 提出 Service Mesh 的 公司 Buoyant 开 源 » 


创始 人 来 自 Twitter 

e Envoy : https://www.envoyproxy.io/，Lyft 开 源 的 ， 可 以 在 lstio 中 使 用 Sidecar 模 
式 运行 

e Istio : https:Wistio.io， 由 Google、IBM、Lyft 联 合 开 发 并 开源 

e Conduit : https://conduit.io， 同 样 由 Buoyant 开 源 的 轻 量 级 的 基于 Kubernetes 
的 Service Mesh 


此 外 还 有 很 多 其 它 的 Service Mesh 鱼贯 而 出 ， 请 参考 awesome-cloud-native ° 
Istio VS Linkerd 


Linkerd#?Istio € 32-7 Ft 7$ 49 Service Mesh， 它 们 都 支持 Kubernetes， 下 面 是 它们 之 
间 的 一 些 特 性 对 比 。 


Feature Istio Linkerd 
部 署 架 构 Envoy/Sidecar DaemonSets 
多 用 性 复杂 简单 
支持 平台 kuberentes kubernetes/mesos/Istio/local 
当前 版 本 0.3.0 139 
是 否 已 有 生产 部 署 T 是 


关于 两 者 的 架构 可 以 参考 各 自 的 官方 文档 ， 我 只 从 其 在 kubernetes 上 的 部 署 结构 来 
说 明 其 区 别 。 


云 原 生 应 用 之 路 一 “从 Kubernetes 到 Cloud Native 





Istio vs Linkerd 


Istio Linkerd 








https://jimmysong.io 





图 片 - istio vs linkerd 


lstio 的 组 件 复 杂 ， 可 以 分 别 部 署 的 kubernetes 集 群 中 ， 但 是 作为 核心 路 由 组 件 
Envoy 是 以 Sidecar 形 式 与 应 用 运行 在 同一 个 Pod 中 的 ， 所 有 进入 该 Pod 中 的 流量 都 
需要 先 经 过 Envoy ° 


Linker 的 部 署 十 分 简单 ， 本 身 就 是 一 个 镜像 ， 使 用 Kubernetes 的 DaemonSet 方 式 在 
每 个 node 节 点 上 运行 。 


更 多 信息 请 参考 kubernetes-handbook ° 
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云 原 生 应 用 之 路 从 Kubernetes 到 Cloud Native 


使 用 场景 


Cloud Native 的 大 规模 工业 生产 





图 片 - Cloud Native factory 


GitOps 


给 开发 者 带 来 最 大 配置 和 上 线 的 灵活 性 ， 践 行 DevOps 流 程 ， 改 善 研发 效率 ， 下 图 
这 样 的 情况 将 更 少 发 生 。 
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EA - Deployment pipeline 


我 们 知道 Kubernetes 中 的 所 有 应 用 SUR US AMEA N ， 这 实际 上 就 是 一 
种 Infrastructure as code， 完 全 可 以 通过 Git 来 管控 基础 设施 和 部 署 环境 的 变更 。 


Big Data 


Spark 现 在 已 经 非 官方 支持 了 基于 Kuberentes 的 原生 调度 ， 其 具有 以 下 特点 : 


云 原生 应 用 之 路 从 Kubernetes 到 Cloud Native 





e Kubernetes 原 生 调 度 
e 资源 隔离 ， 粒 度 更 细 : 


: 与 yarn、 
namespace; X| 2- Jf] P 


mesos F) 2Z& 


。 监控 的 变革 : 单 次 任务 资源 计量 
e 日 志 的 变革 : pod 的 日 志 收 集 


Feature 
queue 
instance 
network 
heterogeneous 


security 


queue 


Yarn 


ExcutorContainer 


host 
no 


RBAC 


下 图 是 在 Kubernetes 上 运行 三 种 调度 


Kubernetes 
namespace 
Executor Pod 
plugin 
yes 
ACL 


方式 的 spark 的 单个 节点 的 应 用 部 分 对 比 : 





Yarn 


NodeManager 


App1 Executor 


App2 Executor 








Spark on Kubernetes with different schedulers 


Standalone 








Kubelet node | 


App1 Executor 


App1 Executor 


App2 Executor 











Native 





Kubelet node 








https://jimmysong.io 





& - Spark on Kubernetes with different schedulers 


从 上 图 中 可 以 看 到 在 Kubernetes 上 使 用 YARN 调 度 
原生 调度 的 方式 ， 每 个 node 节 点 上 的 Pod 内 的 spark Executor 分 布 ， 毫 无 疑问 ， 使 


用 kubernetes 原 生 调 度 的 spark 任 务 才 是 最 节省 资 


提交 任务 的 语句 看 起 来 会 像 是 


这 样 的 : 


JR) 


Æ ` standalone? /Z fekubernetes 
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./spark-submit ^ 

--deploy-mode cluster \ 

--class com.talkingdata.alluxio.hadooptest \ 

--master k8s://https://172.20.0.113:6443 \ 

--kubernetes-namespace spark-cluster \ 

--conf spark. kubernetes.driverEnv.SPARK_USER=hadoop \ 

--conf spark.kubernetes.driverEnv.HADOOP_USER_NAME=hadoop \ 

--conf spark.executorEnv.HADOOP_USER_NAME=hadoop \ 

--conf spark.executorEnv.SPARK_USER=hadoop \ 

--conf spark. kubernetes.authenticate.driver.serviceAccountName= 
spark \ 

--conf spark.driver.memory=100G \ 

--conf spark.executor.memory=10G \ 

--conf spark.driver.cores=30 \ 

--conf spark.executor.cores=2 \ 

--conf spark.driver.maxResultSize=10240m \ 

--conf spark. kubernetes.driver.limit.cores=32 \ 

--conf spark. kubernetes.executor.limit.cores=3 \ 

--conf spark. kubernetes.executor.memoryOverhead=2g \ 

--conf spark.executor.instances=5 \ 

--conf spark.app.name=spark-pi \ 

--conf spark.kubernetes.driver.docker.image-spark-driver:v2.1. 
0-kubernetes-0.3.1-1 \ 

--conf spark.kubernetes.executor.docker.image-spark-executor:v 
2.1.0-kubernetes-0.3.1-1 \ 

--conf spark.kubernetes.initcontainer.docker.image-spark-init: 
v2.1.0-kubernetes-0.3.1-1 \ 

--conf spark.kubernetes.resourceStagingServer.uri-http://172.2 
0.0.114:31000 \ 
~/Downloads/tendcloud_2.10-1.0.jar 


——— ee 


关于 支持 Kubernetes 原 生 调 度 的 Spark 请 参考 : https://jimmysong.io/spark-on-k8s/ 


Open Source 


Contributing is Not only about code, it is about helping a community. 


下 图 是 我 们 刚 调研 准备 使 用 Kubernetes 时 候 的 调研 方案 选择 。 


云 原 生 应 用 之 路 一 一 从 Kubernetes 到 Cloud Native 


Dockerfile 
前 台 执 行 


TORENA MAA 


secret 


拿 出 一 个 具体 的 服务 从 镜像 制作 到 上 
线 的 具体 流程 拆 分 




















package 管 理 





实际 改造 案例 






应 用 级 服务 发 现 


依然 单机 单 节点 部 署 ? 还 是 使 用 
kbuernetes? 
身份 权限 验证 要 做 吗 ? Harbor 镜 像 仓 库 


基础 镜像 制作 ， 不 能 所 有 镜像 都 基于 
CentOS， 浪 费 空间 ， 可 以 参考 下 


Google 的 官方 基础 镜像 


OWL 











Kubernetes Dashboard 仅 作为 后 台 
管理 入 口 


服务 最 终 如 何 访问 ， 统 一 入 口 ， 转 发 
到 ClusterIP 


如 何 创建 服务 ? 通过 Yaml? 通 过 图 形 


化 界面 ?还 是 通过 Jenkins 的 模板 ? 


仍 未 发 布 1.0 正 式 版 


使 用 plugin 方 式 安装 依然 无 法 运行 ， 





LATE, CBRL, FERE 





网 络 产品 化 做 的 比较 好 ， 有 些 企业 已 经 在 
使 用 ， 比 contiv 稳 定 


pros: 与 kubernetes 结 合 比较 好 ， 原 


生 支 持 
cons: 浪费 IP 地 址 


不 支持 非 overlay 网 络 


不 追求 新 版 本 新 特性 ， 使 用 


kubernetes 时 docker 新 版 的 这 些 特性 
k 
并 没有 什么 用 ， 建 议 使 用 


docker1.12.5 


docker plugint T RHA ALIA 
| 
身份 权限 验证 
Rook 基 于 Ceph 


Jenkinsiifthttps://github.com/ 


jenkinsci/kubernetes-plugin 
BERR, RREFEN 


SkyDNS 





持久 化 存储 


DNS 


图 片 - Kubernetes solutions 
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对 于 一 个 初次 接触 Kubernetes 的 人 来 说 ， 看 到 这 样 一 个 庞大 的 架构 选 型 时 会 望 而 生 
Z 
g 


长， 但 是 Kubernetes 的 开源 社区 帮助 了 我 们 很 
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之 路 从 Kubernetes 到 Cloud Native 
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Architecture 
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CLI 
Cluster Lifecycle 
Cluster Ops 


Contributor Experence 






Instrumentation 


图 片 - Kubernetes SIG 


RAZ f K8S&Cloud Native X: 4x43 > BA T k8smeetup ` 
KEUC2017 ` kubernetes-docs-cn Kubernetes 官 方 中 文 文档 项 目 。 


有 用 的 资料 和 链接 


e 我 的 博客 : https://jimmysong.io 
e 微 信 群 : k8s&cloud native 实 战 群 ( 见 : https:Wiimmysong.io/about ) 
e Meetup : k8smeetup 
e Cloud Native Go - 基于 Go 和 React 云 原生 Web 应 用 开 
发 ; https://jimmysong.io/cloud-native-go 
e Gitbook : https://jimmysong.io/kubernetes-handbook 
e Cloud native 开 源 生态 : https://jimmysong.io/awesome-cloud-native/ 
e 资料 分 享 整理 https://github.com/rootsongjc/cloud-native-slides-share 
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e i£% 3] ZR :https://immysong.io/migrating-to-cloud-native- 
application-architectures/ 
e KubeCon + CloudNativeCon 2018411 A 14-155 Lit 
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Kubernetes 2:7 


Kubernetes 最 初 源 于 谷歌 内 部 的 Borg， 提 供 了 面向 应 用 的 容器 集群 部 署 和 管理 系 
统 。Kubernetes 的 目标 旨 在 消除 编排 物理 /虚拟 计算 ， 网 络 和 存储 基础 设施 的 负担 ， 
并 使 应 用 程序 运营 商 和 开发 人 员 完 全 将 重点 放 在 以 容器 为 中 心 的 原 语 上 进行 自助 运 
营 。Kubernetes 也 提供 稳定 、 兼 容 的 基础 (平台 ) ， 用 于 构建 定制 化 的 workflows 
和 更 高 级 的 自动 化 任务 。 Kubernetes 具备 完善 的 集群 管理 能 力 ， 包 括 多 层次 的 安 
全 防护 和 准 入 机 制 、 多 租户 应 用 支撑 能 力 、 透 明 的 服务 注册 和 服务 发 现 机 制 、 内 建 
负载 均衡 器 、 故 障 发 现 和 自我 修复 能 力 、 服 务 滚动 升级 和 在 线 扩容 、 可 扩展 的 资源 
自动 调度 机 制 、 多 粒度 的 资源 配额 管理 能 力 。 Kubernetes 还 提供 完善 的 管理 工 

具 ， 涵 盖 开 发 、 部 署 测试 、 运 维 监控 等 各 个 环节 。 


Borg fà 4^ 


Borg 是 谷歌 内 部 的 大 规模 集群 管理 系统 ， 负 责 对 谷歌 内 部 很 多 核心 服务 的 调度 和 管 
理 。Borg 的 目的 是 让 用 户 能 够 不 必 操 心 资源 管理 的 问题 ， 让 他 们 专注 于 自己 的 核心 
业务 ， 并 且 做 到 跨 多 个 数据 中 心 的 资源 利用 座 最 大 化 。 


Borg 主 要 由 BorgMaster、Borglet、borgcfg 和 Scheduler 组 成 ， 如 下 图 所 示 







command-line 
tools 









persistent store 
(Paxos) 





[E or ih rg oa Borglet | 








图 片 - Borg 架 构 


e BorgMaster 是 整个 集群 的 大 脑 ， 负 责 维 护 整 个 集群 的 状态 ， 并 将 数据 持久 化 到 
Paxos fä? ; 

e Scheduer 负 责任 务 的 调度 ， 根 据 应 用 的 特点 将 其 调度 到 具体 的 机 器 上 去 : 

e Borglet 负 责 监 正 运行 任务 (在 容器 中 ) ; 

e borgcfg 是 Borg 的 命令 行 工 具 ， 用 于 跟 Borg 系 统 交 互 ， 一 般 通过 一 个 配置 文件 
来 提交 任务 。 


Kubernetes 475 


Kubernetest# -& f Borg) 3t iE 3€ A > rode Pod ` Service ` Labels#* X€ Pod € IP ° 
Kubernetes 的 整体 架构 跟 Borg 非 常 像 ， 如 下 图 所 示 
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图 片 - Kubernetes?& 13 


Kubernetes 主 要 由 以 下 几 个 核心 组 件 组 成 : 


e etcd 保 存 了 整个 集群 的 状态 ; 

e apiserver 提 供 了 资源 操作 的 唯一 入 口 ， 并 提供 认证 、 授 权 、 访 问 控 制 、API 注 
册 和 发 现 等 机 制 ; 

e controller manager 负 责 维 护 集群 的 状态 ， 比 如 故障 检测 、 自 动 扩 展 、 滚 动 更 新 
等 ; 

e Scheduler 负 责 资 源 的 调度 ， 按 照 预定 的 调度 策略 将 Pod 调 度 到 相应 的 机 器 上 s 

e kubelet 负 责 维 护 容 器 的 生命 周期 ， 同 时 也 负责 Volume (CSI) 和 网 络 (CNI) 
的 管理 ; 

e Container runtime fi 74414 3€ VA Podfe È 25 9 E SE iE 43 (CRI) ; 

e kube-proxy 负 责 为 Service 提 供 cluster 内 部 的 服务 发 现 和 负载 均衡 ; 


除了 核心 组 件 ， 还 有 一 些 推荐 的 Add-ons : 


e kube-dns 负 责 为 整个 集群 提供 DNS 服务 
e Ingress Controller 为 服务 提供 外 网 入 口 
e Heapster 提 供 资 源 监 控 

e Dashboard 提 供 GUI 

e Federation 提 供 跨 可 用 区 的 集群 


Kubernetes %49 zr x E 


整体 架构 


图 清晰 表明 了 kubernetes 的 架构 设计 以 及 组 件 之 间 的 通信 协议 。 


Kubernetes' high-level component architecture 
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图 片 - Kuberentes 架 构 (图 片 来 自 于 网 络 ) 


下 面 是 更 抽象 的 一 个 视图 : 


Kubernetes 28 #4) 


Kubernetes Architecture 
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Source: Janakiram MSV THENEWSTACK 


图 片 - Kubemmetes 整 体 架 构 示 意图 


Master 4j 
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Kubernetes 28 #4 


Source: Janakiram MSV 


Node 2 #4) 


Kubernetes Master 


Kubernetes Master 


API Server 加 Controller 


图 片 - Kubernetes master 架 构 示 意图 
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Kubernetes 28 #4 


Kubernetes Node 


Image Registry 






Kubernetes 
Master 


Docker kubelet kube-proxy 





Source: Janakiram MSV THENEWSTACK 


图 片 - kubernetes node 架 构 示 意图 


分 层 架构 


Kubernetes 设 计 理 念 和 功能 其 实 就 是 一 个 类 似 Linux 的 分 层 架 构 ， 如 下 图 所 示 
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Kubernetes 28 #4) 
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图 片 - Kubernetes? £ RI TBA 


e 核心 层 : Kubernetes 最 核心 的 功能 ， 对 外 提供 API 构 建 高 层 的 应 用 ， 对 内 提供 
插件 式 应 用 执行 环境 

e 应 用 层 : 部 署 (无 状态 应 用 、 有 状态 应 用 、 批 处 理 任 务 、 集 群 应 用 等 ) 和 路 由 

(服务 发 现 、 DNS 解 析 等 等 ) 

e 管理 层 : 系统 度量 容器 和 网 络 的 度量 ) ， 自 动 化 (如 自动 扩 
展 、 动 态 Provision 等 ) 以 及 策略 管理 (RBAC、Quota、PSP、NetworkPolicy 
F) 

e 接口 层 : kubectl 命 令 行 工具 、 客 户 端 SDK 以 及 集群 联邦 

e 生态 系统 : 在 接口 层 之 上 的 庞大 容器 集群 管理 调度 的 生态 系统 ， 可 以 划分 为 两 
个 范畴 

o Kubernetes 外 部 : 日 志 、 监 控 、 配 置 管理 、Cl、CD、Workflow、FaaS、 
OTS 应 用 、ChatOps 等 

o Kubernetes 内 部 : CRI、CNI、CVI、 镜 像 仓库 、Cloud Provider、 集 群 自 
身 的 配置 和 管理 等 


关于 分 层 架 构 ， 可 以 关注 下 Kubernetes 社 区 正在 推进 的 Kbernetes architectual 
oie o 


参考 文档 
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Kubernetes 28 #4 


Kubernetes design and architecture 
http://queue.acm.org/detail.cfm?id=2898444 
http://static.googleusercontent.com/media/research.google.com/zh- 
CN//pubs/archive/43438.pdf 
http://thenewstack.io/kubernetes-an-overview 

Kbernetes architectual roadmap#eslide 
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设计 理念 


Kubernetes 的 设计 理念 


Kubernetes 设 计 理 念 与 分 布 式 系统 
分 析 和 理解 Kubernetes 的 设计 理念 可 以 使 我 们 更 深入 地 了 解 Kubernetes 系 统 ， 更 好 


地 利用 它 管理 分 布 式 部 署 的 云 原 生 应 用 ， 另 一 方面 也 可 以 让 我 们 借鉴 其 在 分 布 式 系 
统 设 计 方 面 的 经 验 。 


TARH 


Kubernetes 设 计 理 念 和 功能 其 实 就 是 一 个 类 似 Linux 的 分 层 架 构 ， 如 下 图 所 示 





Erud E | Eo ES EU 
Eg ea gin 8 R3 | E. E 


- 2 ERAT EA 


e. 核心 层 : Kubernetes 最 核心 的 功能 ， 对 外 提供 API 构 建 高 层 的 应 用 ， 对 内 提供 
插件 式 应 用 执行 环境 
e 应 用 层 : BRA (无 状态 应 用 、 有 状态 应 用 、 批 处 理 任务 、 集 群 应 用 等 ) 和 路 由 
(服务 发 现 、 DNS 解析 等 ) 
e 管理 层 : 系统 度量 (如 基础 设施 、 容 器 和 网 络 的 度量 ) ， 自 动 化 (如 自动 扩 
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N 


J& ` sh &Provisiont ) 以 及 策略 管理 (RBAC » Quota ` PSP ` NetworkPolicy 
F) 
e 接口 层 : kubectl 命 令 行 工 具 、 客 户 端 SDK 以 及 集群 联邦 
e 生态 系统 : 在 接口 层 之 上 的 庞大 容器 集群 管理 调度 的 生态 系统 ， 可 以 划分 为 两 
个 范畴 
o Kubernetes 外 部 : 日志、 监控、 配置 管理 、Cl、CD、Workflow、FaaS、 
OTS 应 用 、ChatOps 等 
o Kubernetes 内 部 : CRI、CNI、CVI、 镜 像 仓库 、Cloud Provider、 集 群 自 
身 的 配置 和 管理 等 


API 设 计 原则 


对 于 云 计 算 系 统 ， 系 统 API 实 际 上 处 于 系统 设计 的 统领 地 位 ， 正 如 本 文 前 面 所 说 ， 
kubernetes 集 群 系统 每 支持 一 项 新 功能 ， 引 入 一 项 新 技术 ， 一 定 会 新 引入 对 应 的 
API 对 和 象 ， 支 持 对 该 功能 的 管理 操作 ， 理 解 掌 握 的 API， 就 好 比 抓 住 了 kubernetes 系 
统 的 牛 身子 。Kubernetes 系 统 API 的 设计 有 以 下 几 条 原则 : 


1. 所 有 API 应 该 是 声明 式 的 。 正 如 前 文 所 说 ， 声 明 式 的 操作 ， 相 对 于 命令 式 操 
作 ， 对 于 重复 操作 的 效果 是 稳定 的 ， 这 对 于 容易 出 现 数据 丢失 或 重复 的 分 布 式 
环境 来 说 是 很 重要 的 。 另 外 ， 声 明 式 操作 更 容易 被 用 户 使 用 ， 可 以 使 系统 向 用 
户 隐藏 实现 的 细节 ， 隐 藏 实现 的 细节 的 同时 ， 也 就 保留 了 系统 未 来 持续 优化 的 
可 能 性 。 此 外 ， 声 明 式 的 API， 同 时 隐 含 了 所 有 的 API 对 象 都 是 名 词性 质 的 ， 例 
如 Service、Volume 这 些 API 都 是 名 词 ， 这 些 名 词 描 述 了 用 户 所 期 望 得 到 的 一 个 
目标 分 布 式 对 象 。 

2. API 对 象 是 彼此 互补 而 且 可 组 合 的 。 这 里 面 实 际 是 鼓励 API| 对 象 尽 量 实现 面向 对 
象 设计 时 的 要 求 ， 即 “高 内 聚 ， 松 耦合 "， 对 业务 相关 的 概念 有 一 个 合适 的 分 
解 ， 提 高 分 解 出 来 的 对 象 的 可 重用 性 。 事 实 上 ，Kubernetes 这 种 分 布 式 系统 管 
理 平台 ， 也 是 一 种 业务 系统 ， 只 不 过 它 的 业务 就 是 调度 和 管理 容器 服务 。 

3. 高 层 API 尺 操作 意图 为 基础 设计 。 如 何 能 够 设计 好 API， 跟 如 何 能 用 面向 对 象 的 
方法 设计 好 应 用 系统 有 相通 的 地 方 ， 高 层 设 计 一 定 是 从 业务 出 发 ， 而 不 是 过 早 
的 从 技术 实现 出 发 。 因 此 ， 针 对 Kubernetes 的 高 层 API 设 计 ， 一 定 是 以 
Kubernetes 的 业务 为 基础 出 发 ， 也 就 是 以 系统 调度 管理 容器 的 操作 意图 为 基础 
设计 。 

4. 低层 API 根 据 高 层 API 的 控制 需要 设计 。 设 计 实 现 低层 API 的 目的 ， 是 为 了 被 高 
层 API 使 用 ， 考 虑 减少 宛 余 、 提 高 重用 性 的 目的 ， 低 层 API 的 设计 也 要 以 需求 为 
基础 ， 要 尽量 抵抗 受 技 术 实 现 影 响 的 诱惑 。 


. 尽量 避免 简单 封装 ， 不 要 有 在 外 部 API 无 法 显 式 知道 的 内 部 隐藏 的 机 制 。 简 单 


的 封装 ， 实 际 没有 提供 新 的 功能 ， 反 而 增加 了 对 所 封装 API 的 依赖 性 。 内 部 隐 
藏 的 机 制 也 是 非常 不 利于 系统 维护 的 设计 方式 ， 例 如 PetSet 和 ReplicaSet， 本 
来 就 是 两 种 Pod 集 合 ， 那 么 Kubernetes 就 用 不 同 API 对 象 来 定义 它们 ， 而 不 会 
说 只 用 同一 个 ReplicaSet， 内 部 通过 特殊 的 算法 再 来 区 分 这 个 ReplicaSet 是 有 
状态 的 还 是 无 状态 。 


、API 操 作 复 杂 度 与 对 象 数 量 成 正比 。 这 一 条 主要 是 从 系统 性 能 角度 考虑 ， 要 保 


证 整个 系统 随 着 系统 规模 的 扩大 ， 性 能 不 会 迅速 变 慢 到 无 法 使 用 ， 那 么 最 低 的 
限定 就 是 API 的 操作 复杂 度 不 能 超过 O(N)，N 是 对 象 的 数量 ， 否 则 系统 就 不 具 
备 水 平 伸缩 性 了 。 


. API 对 象 状态 不 能 依赖 于 网 络 连 接 状 态 。 由 于 众所周知 ， 在 分 布 式 环境 下 ， 网 


络 连接 断 开 是 经 常 发 生 的 事情 ， 因 此 要 保证 API 对 象 状 态 能 应 对 网 络 的 不 稳 
定 ，API 对 象 的 状态 就 不 能 依赖 于 网 络 连 接 状 态 。 


. 尽量 避免 让 操作 机 制 依赖 于 全 局 状态 ， 因 为 在 分 布 式 系 统 中 要 保证 全 局 状态 的 


同步 是 非常 困难 的 。 


控制 机 制 设 计 原 则 


控制 逻辑 应 该 只 依赖 于 当前 状态 。 这 是 为 了 保证 分 布 式 系统 的 稳定 可 靠 ， 对 于 
经 常 出 现 局 部 错误 的 分 布 式 系统 ， 如 果 控 制 逻 辑 只 依赖 当前 状态 ， 那 么 就 非常 
容易 将 一 个 暂时 出 现 故障 的 系统 恢复 到 正常 状态 ， 因 为 你 只 要 将 该 系统 重 置 到 
某 个 稳定 状态 ， 就 可 以 自信 的 知道 系统 的 所 有 控制 逻辑 会 开始 按照 正常 方式 运 
行 。 

假设 任何 错误 的 可 能 ， 并 做 容错 处 理 。 在 一 个 分 布 式 系 统 中 出 现 局 部 和 临时 错 
误 是 大 概率 事件 。 错 误 可 能 来 自 于 物理 系统 故障 ， 外 部 系统 故障 也 可 能 来 自 于 
系统 自身 的 代码 错误 ， 依 靠 自己 实现 的 代码 不 会 出 错 来 保证 系统 稳定 其 实 也 是 
难以 实现 的 ， 因 此 要 设计 对 任何 可 能 错误 的 容错 处 理 。 

尽量 避免 复杂 状态 机 ， 控 制 逻辑 不 要 依赖 无 法 监控 的 内 部 状态 。 因 为 分 布 式 系 
统 各 个 子 系统 都 是 不 能 严格 通过 程序 内 部 保持 同步 的 ， 所 以 如 果 两 个 子 系统 的 
控制 逻辑 如 果 互 相 有 影响 ， 那 么 子 系 统 就 一 定 要 能 互相 访问 到 影响 控制 逻辑 的 
状态 ， 否 则 ， 就 等 同 于 系统 里 存在 不 确定 的 控制 逻辑 。 

假设 任何 操作 都 可 能 被 任何 操作 对 象 拒 绝 ， 甚 至 被 错误 解析 。 由 于 分 布 式 系统 
的 复杂 性 以 及 各 子 系统 的 相对 独立 性 ， 不 同 子 系统 经 常 来 自 不 同 的 开发 团队 ， 
所 以 不 能 奢望 任何 操作 被 另 一 个 子 系统 以 正确 的 方式 处 理 ， 要 保证 出 现 错误 的 
时 候 ， 操 作 级 别 的 错误 不 会 影响 到 系统 稳定 性 。 

每 个 模块 都 可 以 在 出 错 后 自动 恢复 。 由 于 分 布 式 系统 中 无 法 保证 系统 各 个 模块 


是 始终 连接 的 ， 因 此 每 个 模块 要 有 自我 修复 的 能 力 ， 保 证 不 会 因为 连接 不 到 其 
他 模块 而 自我 前 溃 。 

e 每 个 模块 都 可 以 在 必要 时 优雅 地 降级 服务 。 所 谓 优雅 地 降级 服务 ， 是 对 系统 鲁 
棒 性 的 要 求 ， 即 要 求 在 设计 实现 模块 时 划分 清楚 基本 功能 和 高 级 功能 ， 保 证 基 
本 功能 不 会 依赖 高 级 功能 ， 这 样 同 时 就 保证 了 不 会 因为 高 级 功能 出 现 故障 而 导 
致 整个 模块 崩溃 。 根 据 这 种 理念 实现 的 系统 ， 也 更 容易 快速 地 增加 新 的 高 级 功 
能 ， 因 为 不 必 担 心 引 入 高 级 功能 影响 原 有 的 基本 功能 。 


Kubernetes 的 核心 技术 概念 和 API 对 象 


API 对 象 是 Kubernetes 集 群 中 的 管理 操作 单元 。Kubernetes 集 群 系统 每 支持 一 项 新 
功能 ， 引 入 一 项 新 技术 ， 一 定 会 新 引入 对 应 的 API 对 象 ， 支 持 对 该 功能 的 管理 操 
作 。 例 如 副本 集 Replica Set 对 应 的 API 对 象 是 RS 。 


每 个 API 对 象 都 有 3 大 类 属性 : 元 数据 metadata、 规 范 spec 和 状态 status。 元 数据 是 
用 来 标识 API 对 象 的 ， 每 个 对 象 都 至 少 有 3 个 元 数据 : namespace，name 和 uid ; 除 
此 以 外 还 有 各 种 各 样 的 标签 labels 用 来 标识 和 匹配 不 同 的 对 象 ， 例 如 用 户 可 以 用 标 
签 env 来 标识 区 分 不 同 的 服务 部 署 环 境 ， 分 别 用 env=dev、env=testing 、 
env=production 来 标识 开发 、 测 试 、 生 产 的 不 同 服务 。 规 范 描述 了 用 户 期 望 
Kubernetes 集 群 中 的 分 布 式 系统 达到 的 理想 状态 (Desired State) ， 例 如 用 户 可 以 
通过 复制 控制 器 Replication Controller 设 置 期 望 的 Pod 副 本 数 为 3 ; status 描 述 了 系 
统 实际 当前 达到 的 状态 (Status) ， 例 如 系统 当前 实际 的 Pod 副 本 数 为 2 ; 那么 复制 
控制 器 当前 的 程序 逻辑 就 是 自动 启动 新 的 Pod， 争 取 达 到 副本 数 为 3。 


Kubernetes 中 所 有 的 配置 都 是 通过 API 对 象 的 spec 去 设置 的 ， 也 就 是 用 户 通过 配置 
系统 的 理想 状态 来 改变 系统 ， 这 是 Kubernetes 重 要 设计 理念 之 一 ， 即 所 有 的 操作 都 
是 声明 式 (Declarative) 的 而 不 是 命令 式 (Imperative) 的 。 声 明 式 操作 在 分 布 式 
系统 中 的 好 处 是 稳定 ， 不 怕 丢 操作 或 运行 多 次 ， 例 如 设置 副本 数 为 3 的 操作 运行 多 
次 也 还 是 一 个 结果 ， 而 给 副本 数 加 1 的 操作 就 不 是 声明 式 的 ， 运 行 多 次 结果 就 错 
Sus 


Pod 


Kubernetes 有 很 多 技术 概念 ， 同 时 对 应 很 多 API 对 象 ， 最 重要 的 也 是 最 基础 的 是 
Pod。Pod 是 在 Kubernetes 集 群 中 运行 部 署 应 用 或 服务 的 最 小 单元 ， 它 是 可 以 支持 
多 容器 的 。Pod 的 设计 理念 是 支持 多 个 容器 在 一 个 Pod 中 共享 网 络 地 址 和 文件 系 


统 ， 可 以 通过 进程 间 通 信和 文件 共享 这 种 简单 高 效 的 方式 组 合 完成 服务 。Pod 对 多 
容器 的 支持 是 K8 最 基础 的 设计 理念 。 比 如 你 运行 一 个 操作 系 E , 
一 个 Nginx 容 器 用 来 发 布 软 件 ， 另 一 个 容器 专门 用 来 从 源 仓库 做 同步 ， 这 两 个 容 

的 镜像 不 太 可 能 是 一 个 团队 开发 的 ， 但 是 他 们 一 块 儿 工 作 才 外 LR ARAS ; 这 
种 情况 下 ， 不 同 的 团队 各 自 开 发 构建 自己 的 容器 镜像 ， 在 部 署 的 时 候 组 合成 一 个 微 
服务 对 外 提供 服务 。 


Pod 是 Kubernetes 集 群 中 所 有 业务 类 型 的 基础 ， 可 以 看 作 运 行 在 K8 集 群 中 的 小 机 器 
人 ， 不 同类 型 的 业务 就 需要 不 同类 型 的 小 机 器 人 去 执行 。 目 前 Kubernetes 中 的 业务 
主要 可 以 分 为 长 期 伺服 型 (long-running) 、 批 处 理 型 (batch) 、 节 点 后 人 台 支 撑 型 

(node-daemon) 和 有 状态 应 用 型 (stateful application) ; 分 别 对 应 的 小 机 器 人 
控制 器 为 Deployment、Job、DaemonSet 和 PetSet， 本 文 后 面 会 一 一 介绍 。 


副本 控制 器 (Replication Controller > RC) 


RC 是 Kubernetes 集 群 中 最 早 的 保证 Pod 高 可 用 的 API 对 象 。 通 过 监控 运行 中 的 Pod 
来 保证 集群 中 运行 指定 数目 的 Pod 副 本 。 指 定 的 数目 可 以 是 多 个 也 可 以 是 1 个 ; 少 于 
指定 数目 ，RC 就 会 启动 运行 新 的 Pod 副 本 ; 多 于 指定 数目 ，RC 就 会 杀 死 多 余 的 
Pod 副 本 。 即 使 在 指定 数目 为 1 的 情况 下 ， 通 过 RC 运 行 Pod 也 比 直接 运行 Pod 更 明 
智 ， 因 为 RC 也 可 以 发 挥 它 高 可 用 的 能 力 ， 保 证 永远 有 1 个 Pod 在 运行 。RC 是 
Kubernetes 较 早期 的 技术 概念 ， 只 适用 于 长 期 伺服 型 的 业务 类 型 ， 比 如 控制 小 机 器 
人 提供 高 可 用 的 Web 服 务 。 


副本 集 (Replica Set > RS) 


RS 是 新 一 代 RC， 提 供 同 样 的 高 可 用 能 力 ， 区 别 主 要 在 于 RS 后 来 居 上 ， 能 支持 更 多 
种 类 的 匹配 模式 。 副 本 集 对 象 一 般 不 单独 使 用 ， 而 是 作为 Deployment 的 理想 状态 参 
数 使 用 。 


28% (Deployment) 


部 署 表示 用 户 对 Kubernetes 集 群 的 一 次 更 新 操作 。 部 署 是 一 个 比 RS 应 用 模式 更 广 
的 API 对 象 ， 可 以 是 创建 一 个 新 的 服务 ， 更 新 一 个 新 的 服务 ， 也 可 以 是 滚动 升级 一 
个 服务 。 滚 动 升级 一 个 服务 ， 实 际 是 创建 一 个 新 的 RS， 然 后 逐渐 将 新 RS 中 副本 数 


增加 到 理想 状态 ， 将 昌 RS 中 的 副本 数 减 小 到 0 的 复合 操作 ; 这 样 一 个 复合 操作 用 一 
个 RS 是 不 太 好 描述 的 ， 所 以 用 一 个 更 通用 的 Deployment 来 描述 。 以 Kubernetes 的 
发 展 方向 ， 未 来 对 所 有 长 期 伺服 型 的 的 业务 的 管理 ， 都 会 通过 Deployment 来 管理 。 


服务 (Service) 


RC、RS 和 Deployment 只 是 保证 了 支撑 服务 的 微服 务 Pod 的 数量 ， 但 是 没有 解决 如 
何 访 问 这 些 服务 的 问题 。 一 个 Pod 只 是 一 个 运行 服务 的 实例 ， 随 时 可 能 在 一 个 节点 
上 停止 ， 在 另 一 个 节点 以 一 个 新 的 |P 启 动 一 个 新 的 Pod， 因 此 不 能 以 确定 的 IP 和 端 
口号 提供 服务 。 要 稳定 地 提供 服务 需要 服务 发 现 和 负载 均衡 能 力 。 服 务 发 现 完成 的 
工作 ， 是 针对 客户 端 访 问 的 服务 ， 找 到 对 应 的 的 后 端 服务 实例 。 在 K8 集 群 中 ， 客 户 
端 需要 访问 的 服务 就 是 Service 对 象 。 每 个 Service 会 对 应 一 个 集群 内 部 有 效 的 虚拟 
IP， 集 群 内 部 通过 虚拟 IP 访 问 一 个 服务 。 在 Kubernetes 集 群 中 微服 务 的 负载 均衡 是 
由 Kube-proxy 实 现 的 。Kube-proxy 是 Kubernetes 集 群 内 部 的 负载 均衡 器 。 它 是 一 个 
分 布 式 代理 服务 器 ， 在 Kubernetes 的 每 个 节点 上 都 有 一 个 ; 这 一 设计 体现 了 它 的 伸 
缩 性 优势 ， 需 要 访问 服务 的 节点 越 多 ， 提 供 负 载 均衡 能 力 的 Kube-proxy 就 越 多 ， 高 
可 用 节点 也 随 之 增多 。 与 之 相 比 ， 我 们 平时 在 服务 器 端 做 个 反 向 代理 做 负载 均衡 ， 
还 要 进一步 解决 反 向 代理 的 负载 均衡 和 高 可 用 问题 。 


任务 (Job) 


Job 是 Kubernetes 用 来 控制 批 处 理 型 任务 的 API 对 象 。 批 处 理 业 务 与 长 期 伺服 业务 的 
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远 运行 。Job 管 理 的 Pod 根 据 用户 的 设置 把 任务 成 功 完 成 就 自动 退出 了 。 成 功 完成 的 
标志 根据 不 同 的 spec.completions 策 略 而 不 同 : 单 Pod 型 任 a 志 
完成 ; 定数 成 功 型 任务 保证 有 N 个 任务 全 部 成 功 ; 工作 队列 型 任务 根据 应 用 确认 的 
全 局 成 功 而 标志 成 功 。 


后 台 支 撑 服 务 集 (DaemonSet) 


o d es ne ， 可 能 有 些 节点 运行 多 个 同类 业务 的 
Pod， 有 些 节点 上 又 没有 这 类 Pod 运 行 ; 而 后 侣 支撑 型 服务 的 核心 关注 点 在 
Kubernetes 集 群 中 的 节点 o ， 要 保证 每 个 节点 cat 
Pod 运 行 。 节 点 可 能 是 所 有 集群 节点 也 可 能 是 通过 nodeSelector 选 定 的 一 些 特定 

点 。 殿 型 的 后 台 支 撑 型 服务 包括 ， 存 储 ， 日 志和 监控 等 在 每 个 节点 上 支持 
Kubernetes 和 集群 运行 的 服务 。 


有 状态 服务 集 (PetSet) 


Kubernetes 在 1.3 版 本 里 发 布 了 Alpha 版 的 PetSet 功 能 。 在 云 原 生 应 用 的 体系 里 ， 有 
下 面 两 组 近义词 ; 第 一 组 是 无 状态 〈stateless) 、 牲 畜 (cattle) 、 无 名 
(nameless) ^ T&# (disposable) ; 第 二 组 是 有 状态 (stateful) 、 完 物 
(pet) 、 有 名 (having name) 、 不 可 丢弃 (non-disposable) 。RC 和 RS 主要 是 
控制 提供 无 状态 服务 的 ， 其 所 控制 的 Pod 的 名 字 是 随机 设置 的 ， 一 个 Pod 出 故障 了 
就 被 丢弃 掉 ， 在 另 一 个 地 方 重启 一 个 新 的 Pod， 名 字 妆 了、 名 字 和 启动 在 哪儿 都 不 
重要 ， 重 要 的 只 是 Pod 总 数 ; 而 PetSet 是 用 来 控制 有 状态 服务 ，PetSet 中 的 每 个 
Pod 的 名 字 都 是 事先 确定 的 ， 不 能 更 改 。PetSet 中 Pod 的 名 字 的 作用 ， 并 不 是 《 千 
与 千 寻 》 的 人 性 原因 ， 而 是 关联 与 该 Pod 对 应 的 状态 。 


对 于 RC 和 RS 中 的 Pod， 一 般 不 挂 载 存 储 或 者 挂 载 共享 存储 ， 保 存 的 是 所 有 Pod 共 享 
的 状态 ，Pod 像 牲畜 一 样 没 有 分 别 ( 这 似乎 也 确实 意味 着 失去 了 人 性 特征 ) ; 对 于 
PetSet 中 的 Pod， 每 个 Pod 挂 载 自己 独立 的 存储 ， 如 果 一 个 Pod 出 现 故 障 ， 从 其 他 节 
点 启动 一 个 同样 名 字 的 Pod， 要 挂 载 上 原来 Pod 的 存储 继续 以 它 的 状态 提供 服务 。 


适合 于 PetSet 的 业务 包括 数据 库 服 务 MySQL 和 PostgreSQL， 集 群 化 管理 服务 
Zookeeper、etcd 等 有 状态 服务 。PetSet 的 另 一 种 典型 应 用 场景 是 作为 一 种 比 普通 
容器 更 稳定 可 靠 的 模拟 虚拟 机 的 机 制 。 传 统 的 虚拟 机 正 是 一 种 有 状态 的 完 物 ， 运 维 
人 员 需 要 不 断 地 维护 它 ， 容 器 刚 开 始 流行 时 ， 我 们 用 容器 来 模拟 虚拟 机 使 用 ， 所 有 
状态 都 保存 在 容器 里 ， 而 这 已 被 证 明 是 非常 不 安全 、 不 可 靠 的。 使 用 PetSet，Pod 
仍然 可 以 通过 漂移 到 不 同 节点 提供 高 可 用 ， 而 存储 也 可 以 通过 外 挂 的 存储 来 提供 高 
可 靠 性 ，PetSet 做 的 只 是 将 确定 的 Pod 与 确定 的 存储 关联 起 来 保证 状态 的 连续 性 。 
PetSet 还 只 在 Alpha 阶 段 ， 后 面 的 设计 如 何 演变 ， 我 们 还 要 继续 观察 。 


集群 联邦 (Federation) 


Kubernetes 在 1.3 版 本 里 发 布 了 beta 版 的 Federation 功 能 。 在 云 计 算 环境 中 ， 服 务 的 
作用 距离 范围 从 近 到 远 一 般 可 以 有 : 同 主机 (Host: Node) 、 跨 主机 同 可 用 区 

(Available Zone) 、 跨 可 用 区 同 地 区 (Region) 、 跨 地 区 同 服务 商 (Cloud 
Service Provider) 、 跨 云 平 台 。Kubernetes 的 设计 定位 是 单一 集群 在 同一 个 地 域 
内 ， 因 为 同一 个 地 区 的 网 络 性 能 才能 满足 Kubernetes 的 调度 和 计算 存储 连接 要 求 。 
而 联合 集群 服务 就 是 为 提供 跨 Region 跨 服务 商 Kubernetes 集 群 服务 而 设计 的 。 


每 个 Kubernetes Federation 有 自己 的 分 布 式 存 储 、API Serverfe Controller 
Manager。 用 户 可 以 通过 Federation 的 API Server 注 册 该 Federation 的 成 员 
Kubernetes Cluster。 尖 用 户 通过 Federation 的 API Server 创 建 、 更 改 API 对 象 时 ， 
Federation API Server 会 在 自己 所 有 注册 的 子 Kubernetes Cluster 都 创建 一 份 对 应 
的 API 对 象 。 在 提供 业务 请 求 服务 时 ，Kubernetes Federation 会 先 在 自己 的 各 个 子 
Cluster 之 间 做 负载 均衡 ， 而 对 于 发 送 到 某 个 具体 Kubernetes Cluster 的 业务 请 求 ， 
会 依照 这 个 Kubernetes Cluster 独 立 提 供 服务 时 一 样 的 调度 模式 去 做 Kubernetes 
Cluster 内 部 的 负载 均衡 。 而 Cluster 之 间 的 负载 均衡 是 通过 域名 服务 的 负载 均衡 来 实 
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所 有 的 设计 都 尽量 不 影响 Kubernetes Cluster 现 有 的 工作 机 制 ， 这 样 对 于 每 个 子 
Kubernetes 集 群 来 说 ， 并 不 需要 更 外 层 的 有 一 个 Kubernetes Federation， 也 就 是 意 
味 着 所 有 现 有 的 Kubernetes 代 码 和 机 制 不 需要 因为 Federation 功 能 有 任何 变化 。 


4 fi % (Volume) 


peers 的 存储 卷 跟 Docker 的 存储 卷 有 些 类 似 ， 只 不 过 Docker 的 存储 卷 
作用 范 个 容器 ， 而 Kubernetes 的 存储 卷 的 生命 周期 和 作用 范围 是 一 个 Pod。 
ee j AB ft BMP odt 的 所 有 容器 共享 。Kubernetes 支 持 非 常 多 的 存储 
卷 类 型 ， 特 别 的 ， 支 持 多 种 公有 云 平 台 的 存储 ， 包括 AWS ， > GooglefeAzurez : X 
持 多 种 分 布 式 存储 包括 GlusterFS 和 Ceph ; 也 支持 较 容 易 使 用 的 主机 本 地 目录 
hostPath 和 NFS。Kubernetes 还 支持 使 用 Persistent Volume Claim PP PVC 2 4 3 44 
存储 ， 使 用 这 种 存储 ， 使 得 存储 的 使 用 者 可 以 忽略 后 人 台 的 实际 存储 技术 (例如 
AWS > GoogleXGlusterFSfeCeph) ， 而 将 有 关 和 存储 实际 技术 的 配置 交 给 存储 管理 
员 通 过 Persistent Volume 来 配置 。 


持久 存储 卷 (Persistent Volume : PV) 和 持久 存储 卷 
声明 (Persistent Volume Claim * PVC) 


PV 和 PVC 使 得 Kubernetes 集 群 具 备 了 存储 的 逻辑 抽象 能 力 ， 使 得 在 配置 Pod 的 逻辑 
里 可 以 忽略 对 实际 后 台 存 储 技术 的 配置 ， 而 把 这 项 配置 的 工作 交 给 PV 的 配置 者 ， 即 
集群 的 管理 者 。 存 储 的 PV 和 PVC 的 这 种 关系 ， 跟 计算 的 Node 和 Pod 的 关系 是 非常 

类 似 的 ; PV 和 Node 是 资源 的 提供 者 ， 根 据 集 群 的 基础 设施 变化 而 变化 ， 由 
Kubernetes 集 群 管理 员 配 置 ; 而 PYVC 和 Pod 是 资源 的 使 用 者 ， 根 据 业 务 服务 的 需求 
变化 而 变化 ， 有 Kubernetes 集 群 的 使 用 者 即 服务 的 管理 员 来 配置 。 


点 (Node) 


Kubernetes 集 群 中 的 计算 能 力 由 Node 提 供 ， 最 初 Node 称 为 服务 节点 Minion， 后 来 
改名 为 Node。Kubernetes 集 群 中 的 Node 也 就 等 同 于 Mesos 集 群 中 的 Slave 节 点 ， 是 
所 有 Pod 运 行 所 在 的 工作 主机 ， 可 以 是 物理 机 也 可 以 是 虚拟 机 。 不 论 是 物理 机 还 是 
虚拟 机 ， 工 作 主 机 的 统一 特征 是 上 面 要 运行 Kubelet 管 理 节点 上 运行 的 容器 


ARX E (Secret) 


Secret 是 用 来 保存 和 传递 密码 、 密 钥 、 认 证 凭证 这 些 敏感 信息 的 对 象 。 使 用 Secret 
的 好 处 是 可 以 避免 把 敏感 信息 明文 写 在 配置 文件 里 。 在 Kubernetes 集 群 中 配置 和 使 
用 服务 不 可 避免 的 要 用 到 各 种 敏感 信息 实现 登录 、 认 证 等 功能 ， 例 如 访问 AWS 存 储 
的 用 户 名 密码 。 为 了 避免 将 类 似 的 敏感 信息 明文 写 在 所 有 需要 使 用 的 配置 文件 中 ， 

可 以 将 这 些 信息 存 入 一 个 Secret 对 象 ， 而 在 配置 文件 中 通过 Secret 对 象 引 用 这 些 敏 

感 信 息 。 这 种 方式 的 好 处 包括 : 意图 明确 ， 避 免 重 复 ， 减 少 暴 漏 机 会 。 


APEP (User Account) 和 服务 帐户 (Service 
Account) 


顾名思义 ， 用 户 帐 户 为 人 提供 账户 标识 ， 而 服务 账户 为 计算 机 进程 和 Kubernetes 集 
群 中 运行 的 Pod 提 供 账 户 标 识 。 用 户 帐户 和 服务 帐户 的 一 个 区 别 是 作用 范围 AP 
帐户 对 应 的 是 人 的 身份 ， 人 的 身份 与 服务 的 namespace 无 关 ， 所 以 用 户 账户 是 跨 
namespace*) ; 而 服务 帐户 对 应 的 是 一 个 运行 中 程序 的 身份 ， 与 特定 namespace 是 
相关 的 。 


命名 空间 (Namespace) 


命名 空间 为 Kubernetes 集 群 提供 虚拟 的 隔离 si 用 ，Kubernetes 集 群 初 始 有 两 个 命名 
空间 ， 分 别 是 默认 命名 空间 default 和 系统 命名 空间 kube-system， 除 此 以 外 ， 管 理 
员 可 以 可 以 创建 新 的 命名 空间 满足 需要 。 


RBAC7; i7] j& 4x 


Kubernetes 在 1.3 版 本 中 发 布 了 alpha 版 的 基于 角色 的 访问 控制 ( Role-based 
Access Control > RBAC) 的 授权 模式 。 相 对 于 基于 属性 的 访问 控制 (Attribute- 
based Access Control > ABAC) ，RBAC 主 要 是 引入 了 角色 (Role) 和 角色 绑 定 


(RoleBinding) 的 抽象 概念 。 在 ABAC 中 ，Kubernetes 集 群 中 的 访问 策略 只 能 跟 用 
户 直 接 关联 ; 而 在 RBAC 中 ， 访 问 策略 可 以 跟 某 个 角色 关联 ， 具 体 的 用 户 在 跟 一 个 
或 多 个 角色 相关 联 。 显 然 ，RBAC 像 其 他 新 功能 一 样 ， 每 次 引入 新 功能 ， 都 会 引入 
新 的 API 对 象 ， 从 而 引入 新 的 概念 抽象 ， 而 这 一 新 的 概念 抽象 一 定 会 使 集群 服务 管 
理 和 使 用 更 容易 扩展 和 重用 。 


e 


Cx 


4 


从 Kubernetes 的 系统 架构 、 技 术 概 念 和 设计 理念 ， 我 们 可 以 看 到 Kubernetes 系 统 最 
核心 的 两 个 设计 理念 : 一 个 是 容错 性 ， 一 个 是 易 扩 展 性 。 容 错 性 实际 是 保证 
Kubernetes 系 统 稳定 性 和 安全 性 的 基础 ， 易 扩展 性 是 保证 Kubernetes 对 变更 友好 ， 
可 以 快速 迭代 增加 新 功能 的 基础 。 


按照 分 布 式 系统 一 致 性 算法 Paxos 发 明 人 计算 机 科学 家 Leslie Lamport 的 理念 ， 一 个 
分 布 式 系统 有 两 类 特性 : 安全 性 Safety 和 活性 Liveness。 安 全 性 保证 系统 的 稳定 ， 
保证 系统 不 会 崩溃 ， 不 会 出 现 业务 错误 ， 不 会 做 坏事 ， 是 严格 约束 的 ; 活性 使 得 系 
统 可 以 提供 功能 ， 提 高 性 能 ， 增 加 易 用 性 ， 让 系统 可 以 在 用 户 “看 到 的 时 间 内 ”做 些 
好 事 ， 是 尽力 而 为 的 。Kubernetes 系 统 的 设计 理念 正好 与 Lamport 安 全 性 与 活性 的 
理念 不 谋 而 合 ， 也 正 是 因为 Kubernetes 在 引入 功能 和 技术 的 时 候 ， 非 常 好 地 划分 了 
安全 性 和 活性 ， 才 可 以 让 Kubernetes 能 有 这 么 快 版 本 和 迭代， 快速 引入 像 RBAC、 
Federation 和 PetSet 这 种 新 功能 。 
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Etcd 4247 


Etcd 是 Kubernetes 集 群 中 的 一 个 十 分 重要 的 组 件 ， 用 于 保存 集群 所 有 的 网 络 配置 和 
对 象 的 状态 信息 。 在 后 面具 体 的 安装 环境 中 ， 我 们 安装 的 etcd 的 版 本 是 v3.1.5， 整 
个 kubernetes 系 统 中 一 共有 两 个 服务 需要 用 到 etcd 用 来 协同 和 存储 配置 ， 分 别 是 


e 网 络 插件 flannel、 对 于 其 它 网 络 插件 也 需要 用 到 etcd 存 储 网 络 的 配置 信息 
e kubernetes 本 身 ， 包 括 各 种 对 象 的 状态 和 元 信息 配置 


注意 : flannel 操 作 etcd 使 用 的 是 v2 的 API， 而 kubernetes 操 作 etcd 使 用 e dd , 
所 以 在 下 面 我 们 执行 etcdctl 的 时 候 需 要 设置 ETCDCTL API 环境 变量 ， 该 变 
默认 值 为 2。 


原理 


Etcd 使 用 的 是 raft 一 致 性 算法 来 实现 的 ， 是 一 款 分 布 式 的 一 致 性 KV 存 储 ， 主 要 用 于 
共享 配置 和 服务 发 现 。 关 于 raft 一 致 性 算法 请 参考 该 动画 演示 。 


关于 Etcd 的 原理 解析 请 参考 Etcd 架构 与 实现 解析 。 


i M Etcd 7 f Flannel H 24-42 2 


我 们 在 安装 Flannel 的 时 候 配 置 了 FLANNEL ETCD PREFIX-"/kube- 
centos/network" 参数 ， 这 是 Flannel 查 询 etcd 的 目录 地 址 。 


查看 Etcd 中 存储 的 flannel 网 络 信息 : 


$ etcdctl --ca-file-/etc/kubernetes/ssl/ca.pem --cert-file-/etc/ 
kubernetes/ssl/kubernetes.pem --key-file-/etc/kubernetes/ssl/kub 
ernetes-key.pem ls /kube-centos/network -r 

2018-01-19 18:38:22.768145 I | warning: ignoring ServerName for 
user-provided CA for backwards compatibility is deprecated 

/ kube-centos/network/config 

/ kube-centos/network/subnets 
/kube-centos/network/subnets/172.30.31.0-24 
/kube-centos/network/subnets/172.30.20.0-24 
/kube-centos/network/subnets/172.30.23.0-24 


4 A flannels) &  : 


$ etcdctl --ca-file=/etc/kubernetes/ssl/ca.pem --cert-file=/etc/ 
kubernetes/ssl/kubernetes.pem --key-file-/etc/kubernetes/ssl/kub 
ernetes-key.pem get /kube-centos/network/config 

2018-01-19 18:38:22.768145 I | warning: ignoring ServerName for 
user-provided CA for backwards compatibility is deprecated 

( "Network": "172.30.0.0/16", "SubnetLen": 24, "Backend": ( "Typ 
e": "host-gw" ) } 


f$ M Etcd & 4 Kubernetes 3t 2-43 2% 


Kubernetes 使 用 etcd v3 的 API 操 作 etcd 中 的 数据 。 所 有 的 资源 对 象 都 保存 
在 /registry 路 径 下 ， 如 下 : 


ThirdPartyResourceData 
apiextensions.k8s.io 
apiregistration.k8s.io 
certificatesigningrequests 
clusterrolebindings 
clusterroles 
configmaps 
controllerrevisions 
controllers 

daemonsets 

deployments 

events 
horizontalpodautoscalers 
ingress 

limitranges 

minions 
monitoring.coreos.com 
namespaces 
persistentvolumeclaims 
persistentvolumes 
poddisruptionbudgets 
pods 

ranges 

replicasets 
resourcequotas 
rolebindings 

roles 

secrets 
serviceaccounts 
services 

statefulsets 
storageclasses 
thirdpartyresources 


如 果 你 还 创建 了 CRD ( 自 定义 资源 定义 ) 


查看 集群 中 所 有 的 Pod 信 息 


， 则 在 此 会 出 现 CRD 的 API 。 


例如 我 们 直接 从 etcd 中 查看 kubernetes 集 群 中 所 有 的 pod 的 信息 ， 可 以 使 用 下 面 的 


命令 : 


ETCDCTL_API=3 etcdctl get /registry/pods --prefix -w json|python 


-m json.tool 


此 时 将 看 到 json 格 式 输出 的 结果 ， 其 中 的 key 使 用 了 base64 编码 ， 关 于 etcdctl 
命令 的 详细 用 法 请 参考 使 用 etcdctl 访 问 kubernetes 数 据 。 


Etcd V2 与 V3 版 本 API 的 区 别 


Etcd V2 和 V3 之 问 的 数据 结构 完全 不 同 ， 互 不 兼容 ， 也 就 是 说 使 用 V2 版 本 的 API 创 
建 的 数据 只 能 使 用 V2 的 API 访 问 ，V3 的 版 本 的 API 创 建 的 数据 只 能 使 用 V3 的 API 访 
问 。 这 就 造成 我 们 访问 etcd 中 保存 的 flannel 的 数据 需要 使 用 etcdctl 的 V2 版 本 的 
客户 端 ， 而 访问 kubernetes 的 数据 需要 设置 ETCDCTL_API=3 环境 变量 来 指定 V3 版 
本 的 API。 


Etcd 数 据 备 份 


我 们 安装 的 时 候 指 定 的 Etcd 数 据 的 存储 路 径 是 /var/lib/etcd ， 一 定 要 对 该 目录 
做 好 备份 。 


e etcd 官 方 文档 
e etcd v3 命令 和 API 
e Etcd 架构 与 实现 解析 
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开放 接口 


开放 接口 


Kubernetes 作 为 云 原生 应 用 的 的 基础 调度 平台 ， 相 当 于 云 原生 的 操作 系统 ， 为 了 便 
于 系统 的 扩展 ，Kubernetes 中 开放 的 以 下 接口 ， 可 以 分 别 对 接 不 同 的 后 端 ， 来 实现 
自己 的 业务 逻辑 : 


e CRI (Container Runtime Interface) : 容器 运行 时 接口 ， 提 供 计 算 资 源 
容器 网 络 接口 ， 提 供 网 络 资源 
容器 存储 接口 ， 提 供 存 储 资源 


e CNI (Container Network Interface ) 
e CSI (Container Storage Interface ) 


ph 


以 上 三 种 资源 相当 于 一 个 分 布 式 操作 系统 的 最 基础 的 几 种 资源 类 型 ， 而 Kuberentes 
是 将 他 们 粘 合 在 一 起 的 纽带 。 
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CRI - Container Runtime Interface ( 4 Z5 35 
行 时 接口 ) 


CRI 中 定义 了 容器 和 镜像 的 服务 的 接口 ， 因 为 容器 运行 时 与 镜像 的 生命 周期 是 彼此 
隔离 的 ， 因 此 需要 定义 两 个 服务 。 该 接口 使 用 Protocol Buffer， 基 于 gRPC， 在 
kubernetes v1.7+ 版 本 中 是 在 pkg/kubelet/apis/cri/v1alpha1/runtime 

的 api.proto 中 定义 的 。 


CRI 采 构 


Container Runtime 实 现 了 CRI gRPC Server > & 
括 RuntimeService 和 ImageService 。 该 gRPC Server 需 要 监听 本 地 的 Unix 
socket， 而 kubelet 则 作为 gRPC Client 运 行 










CRI 
protobuf 






grpc 
client 








container 


EH - CRIR4-A H X BE kubernetes blog 


Jz FI CRI 


4s 3E dE 9X, T rktnetes > &MCRIAB AE XX SR M T > kubernetes1.77& AAS 18 45 Tf 
集成 的 docker CRI 已 经 被 移 除 。 


要 想 启 用 CRI 只 需要 在 kubelet 的 启动 参数 重 传 入 此 参数 : --container-runtime- 
endpoint 远程 运行 时 服务 的 端点 。 当 前 Linux 上 支持 unix socket，windows 上 支持 
tcp。 例 如 : unix:///var/run/dockershim.sock ^ 

tcp://localhost:373 ° Rive unix:///var/run/dockershim.sock > BPR 
认 使 用 本 地 的 docker 作 为 容器 运行 时 。 


关于 CRI 的 详细 进展 请 参考 CRI: the Container Runtime Interface ° 


72 OS 


CRI - Container Runtime Interface (容器 运行 时 接口 ) 


CRI# 7 
Kubernetes1.9¥ CRI 7 api.proto 中 的 定义 如 下 : 


// Runtime service defines the public APIs for remote container 
runtimes 
service RuntimeService { 

// Version returns the runtime name, runtime version, and ru 
ntime API version. 

rpc Version(VersionRequest) returns (VersionResponse) {} 


// RunPodSandbox creates and starts a pod-level sandbox. Run 
times must ensure 

// the sandbox is in the ready state on success. 

rpc RunPodSandbox(RunPodSandboxRequest) returns (RunPodSandb 
oxResponse) {} 

// StopPodSandbox stops any running process that is part of 
the sandbox and 

// reclaims network resources (e.g., IP addresses) allocated 

to the sandbox. 

// If there are any running containers in the sandbox, they 
must be forcibly 

// terminated. 

// This call is idempotent, and must not return an error if 
all relevant 

// resources have already been reclaimed. kubelet will call 
StopPodSandbox 

// at least once before calling RemovePodSandbox. It will al 
so attempt to 

// reclaim resources eagerly, as soon as a sandbox is not ne 
eded. Hence, 

// multiple StopPodSandbox calls are expected. 

rpc StopPodSandbox(StopPodSandboxRequest) returns (StopPodSa 
ndboxResponse) {} 

// RemovePodSandbox removes the sandbox. If there are any ru 
nning containers 

// in the sandbox, they must be forcibly terminated and remo 
ved. 

// This call is idempotent, and must not return an error if 
the sandbox has 

// already been removed. 

rpc RemovePodSandbox(RemovePodSandboxRequest) returns (Remov 
ePodSandboxResponse) {} 

// PodSandboxStatus returns the status of the PodSandbox. If 
the PodSandbox is not 

// present, returns an error. 

rpc PodSandboxStatus(PodSandboxStatusRequest) returns (PodSa 
ndboxStatusResponse) {} 

// ListPodSandbox returns a list of PodSandboxes. 

rpc ListPodSandbox(ListPodSandboxRequest) returns (ListPodSa 
ndboxResponse) {} 
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CRI - Container Runtime Interface (容器 运行 时 接口 ) 


// CreateContainer creates a new container in specified PodS 
andbox 

rpc CreateContainer(CreateContainerRequest) returns (CreateC 
ontainerResponse) {} 

// StartContainer starts the container. 

rpc StartContainer(StartContainerRequest) returns (StartCont 
ainerResponse) {} 

// StopContainer stops a running container with a grace peri 
od (i.e., timeout). 

// This call is idempotent, and must not return an error if 
the container has 

// already been stopped. 

// TODO: what must the runtime do after the grace period is 
reached? 

rpc StopContainer(StopContainerRequest) returns (StopContain 
erResponse) {} 

// RemoveContainer removes the container. If the container i 
s running, the 

// container must be forcibly removed. 

// This call is idempotent, and must not return an error if 
the container has 

// already been removed. 

rpc RemoveContainer(RemoveContainerRequest) returns (RemoveC 
ontainerResponse) {} 

// ListContainers lists all containers by filters. 

rpc ListContainers(ListContainersRequest) returns (ListConta 
inersResponse) {} 

// ContainerStatus returns status of the container. If the c 
ontainer is not 

// present, returns an error. 

rpc ContainerStatus(ContainerStatusRequest) returns (Contain 
erStatusResponse) {} 

// UpdateContainerResources updates ContainerConfig of the c 
ontainer. 

rpc UpdateContainerResources(UpdateContainerResourcesRequest ) 

returns (UpdateContainerResourcesResponse) {} 


// ExecSync runs a command in a container synchronously. 

rpc ExecSync(ExecSyncRequest) returns (ExecSyncResponse) {} 

// Exec prepares a streaming endpoint to execute a command i 
n the container. 

rpc Exec(ExecRequest) returns (ExecResponse) {} 

// Attach prepares a streaming endpoint to attach to a runni 
ng container. 

rpc Attach(AttachRequest) returns (AttachResponse) {} 

// PortForward prepares a streaming endpoint to forward port 
s from a PodSandbox. 

rpc PortForward(PortForwardRequest) returns (PortForwardResp 


onse) {} 


// ContainerStats returns stats of the container. If the con 
tainer does not 
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CRI - Container Runtime Interface 〈 容 器 运行 时 接口 ) 


// exist, the call returns an error. 

rpc ContainerStats(ContainerStatsRequest) returns (Container 
StatsResponse) {} 

// ListContainerStats returns stats of all running container 
S. 

rpc ListContainerStats(ListContainerStatsRequest) returns (L 
istContainerStatsResponse) {} 


// UpdateRuntimeConfig updates the runtime configuration bas 
ed on the given request. 

rpc UpdateRuntimeConfig(UpdateRuntimeConfigRequest) returns ( 
UpdateRuntimeConfigResponse) {} 


// Status returns the status of the runtime. 
rpc Status(StatusRequest) returns (StatusResponse) {} 


j 


// ImageService defines the public APIs for managing images. 
service ImageService { 

// ListImages lists existing images. 

rpc ListImages(ListImagesRequest) returns (ListImagesResponse 
) Q 

// ImageStatus returns the status of the image. If the image 
is not 

// present, returns a response with ImageStatusResponse.Imag 
e set to 

// nil. 

rpc ImageStatus(ImageStatusRequest) returns (ImageStatusResp 
onse) {} 

// PullImage pulls an image with authentication config. 

rpc PullImage(PullImageRequest) returns (PullImageResponse) { 


// RemoveImage removes the image. 

// This call is idempotent, and must not return an error if 
the image has 

// already been removed. 

rpc RemoveImage(RemoveImageRequest) returns (RemovelmageResp 


onse) {} 


// ImageFSInfo returns information of the filesystem that is 
used to store images. 
rpc ImageFsInfo(ImageFsInfoRequest) returns (ImageFsInfoResp 


onse) {} 

} 
国定 | 
这 其 中 包含 了 两 个 gRPC 服 务 : 


e RuntimeService : 容器 和 Sandbox 运 行 时 管理 
e ImageService : 提供 了 从 镜像 仓库 拉 取 、 查 看 、 和 移 除 镜像 的 RPC © 
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当前 支持 的 CRI 后 端 


我 们 最 初 在 使 用 Kubernetes 时 通常 会 默认 使 用 Docker 作 为 容器 运行 时 ， 其 实 从 
Kubernetes1.5 开 始 已 经 开始 支持 CRI， 目 前 是 处 于 Alpha 版 本 ， 通 过 CRI 接 口 可 以 
指定 使 用 其 它 容 器 运行 时 作为 Pod 的 后 端 ， 目 前 支持 CRI 的 后 端 有 : 


e cri-o : 同时 兼容 OCl 和 CRI 的 容器 运行 时 

e cri-containerd : 基于 Containerd 的 Kubernetes CRI 实现 

e : 由 于 CoreOS 主 推 的 用 来 跟 docker 抗 衡 的 容器 运行 时 

e frakti : 基于 hypervisor 的 CRI 

e docker : kuberentes 最 初 就 开始 支持 的 容器 运行 时 ， 目 前 还 没完 全 从 kubelet 中 
AES > dockerZ- s] E] i 4& T OC Us 7E 

e clear-containers : TUE ee 器 运行 时 

e kata-containers : 符合 OCI 规 范 同 时 兼容 CRI 


CRI 是 由 SIG-Node 来 维护 的 。 


e Kubernetes CRI and Minikube 

e Kubernetes container runtime interface 

e CRI-O and Alternative Runtimes in Kubernetes 

e Docker ` Containerd ` RunC... : 你 应 该 知道 的 所 有 

e Introducing Container Runtime Interface (CRI) in Kubernetes 
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CNI - Container Network Interface (24 W 
络 接口 ) 


CNI (Container Network Interface) 是 CNCF 旗 下 的 一 个 项 目 ， 由 一 组 用 于 配置 
Linux 容 器 的 网 络 接口 的 规范 和 库 组 成 ， 同 时 还 包 侈 了 一 些 插件 。CNI 仅 关心 容器 外 
建 时 的 网 络 分 配 ， 和 当 容 器 被 删除 时 释放 网 络 资源 。 通 过 此 链接 浏览 该 项 

A : https://github.com/containernetworking/cni ° 


EE 


Kubernetes#% 45 4) vendor/github.com/containernetworking/cni/libcni 4 
录 中 已 经 包含 了 CNI 的 代码 ， 也 就 是 说 kubernetes 中 已 经 内 置 了 CNI。 


接口 定义 
CNI 的 接口 中 包括 以 下 几 个 方法 : 


type CNI interface { 

AddNetworkList(net *NetworkConfigList, rt *RuntimeConf) (typ 
es.Result, error) 

DelNetworkList(net *NetworkConfigList, rt *RuntimeConf) error 


AddNetwork(net *NetworkConfig, rt *RuntimeConf) (types.Result 
, error) 
DelNetwork(net *NetworkConfig, rt *RuntimeConf) error 


OEE 


该 接口 只 有 四 个 方法 ， 添 加 网 络 、 删 除 网 络 、 添 加 网 络 列表 、 删 除 网 络 列表 。 


设计 考量 


CNI 设 计 的 时 候 考虑 了 以 下 问题 : 


e X ZITI S MU 建 一 个 新 的 网 络 命名 空间 。 
e. 然后 ， 运 行 时 必须 确定 这 个 容器 应 属于 哪个 网 络 ， en 2n 


a 
e 网 络 配 置 采 用 JSON 格 式 ， 可 以 很 容易 地 存储 在 文件 中 。 网 络 配置 包括 必 卉 字 


ft> dw name 和 type 以 及 插件 (XA) 。 网 络 配置 允许 字段 在 调用 之 间 改 
变 值 。 为 此 ， 有 一 个 可 选 的 字段 args ， 必 须 包 含 不 同 的 信息 

e 容器 运行 时 必须 按 顺序 为 每 个 网 络 执行 相应 的 插件 ， 将 容器 添加 到 每 个 网 络 
中 o 

e 在 完成 容器 生命 周期 后 ， 和 运行 时 必须 以 相反 的 顺序 执行 播 件 《相对 于 执行 添 力 
容器 的 顺序 ) 以 将 容器 与 网 络 断 开 连 接 。 

e 容器 运行 时 不 能 为 同一 容器 调用 并 行 操作 ， 但 可 以 为 不 同 的 容器 调用 并 行 操 
作 。 


e 容器 运行 时 必须 为 容器 订阅 ADD 和 DEL 操作 ， 这 样 ADD 后 面 总 是 跟着 相应 的 
DEL 。 DEL 可 能 跟着 额外 的 DEL， 但 是 ， 插 件 应 该 允许 处 理 多 个 DEL ( 即 插件 
DELE AA AAA) 。 

e 容器 必须 由 ContainerID 唯 一 标识 。 存 储 状态 的 插件 应 该 使 用 〈 网 络 名 称 ， 容 器 

D) 的 主键 来 完成 。 

运行 时 不 能 调用 同一 个 网 络 名 称 或 容器 ID 执行 两 次 ADD (没有 相应 的 DEL ) © 

换 和 名 话说， 给 定 的 容器 ID 必须 只 能 添加 到 特定 的 网 络 一 次 。 


CNI 插 件 


CNI 插 件 必须 实现 一 个 可 执行 文件 ， 这 个 文件 可 以 被 容器 管理 系统 (例如 rkt 或 
Kubernetes ) 调用 。 


CNI 插 件 负 责 将 网 络 接 口 插入 容器 网 络 命 名 空间 (例如 ，veth 对 的 一 端 ) ， 并 在 主 
机 上 进行 任何 必要 的 改变 (例如 将 veth 的 另 一 端 连接 到 网 枚 ) 。 然 后 将 |P 分 配给 接 
口 ， 并 通过 调用 适当 的 IPAM 插 件 来 设置 与 “|P 地 址 管理 ?部 分 一 致 的 路 由 。 


参数 
CNI 插 件 必 须 支 持 以 下 操作 : 


将 容器 添加 到 网 络 


数 : 


$ 


e 版 本 。 调 用 者 正在 使 用 的 CNI 规 范 (容器 管理 系统 或 调用 插件 ) 的 版 本 。 
e 容器 ID 。 由 运行 时 分 配 的 容器 的 唯一 明文 标识 符 。 一 定 不 能 是 空 的 。 
e 网 络 命名 空间 路 径 。 要 添加 的 网 络 名 称 空 间 的 路 径 

BP /proc/[pid]/ns/net 或 绑 定 挂 载 / 链 接 。 


网 络 配置 。 描 述 容器 可 以 加 入 的 网 络 的 JSON 文 档 。 架 构 如 下 所 述 。 
额外 的 参数 。 这 提供 了 一 个 替代 机 制 ， on 
容器 内 接口 的 名 称 。 这 是 应 该 分 配给 容器 (网 络 命名 空间 ) 内 创建 的 接口 的 名 
称 ; 因此 它 必 须 符 合 Linux 接 口 名 称 上 的 标准 限制 。 


接口 列表 。 根 据 插件 的 不 同 ， 这 可 以 包括 沙 箱 (例如 容器 或 管理 程序 ) 接口 名 
称 和 /或 主机 接口 名 称 ， c cuu n d rH (如 果 有 的 
话 ) 的 详细 信息 

分 配给 每 个 接口 的 IP 配 置 。 分 配给 沙 箱 和 /或 主机 接口 的 |Pv4 和 /或 IPv6 地 址 ， 
网 关 和 路 由 。 


DNS 信 息 。 包 含 nameserver、domain、search domain 和 option 的 DNS 信息 的 
qus 


从 网 络 中 删除 容器 


参数 : 


版 本 。 调 用 者 正在 使 用 的 CNI 规 范 (容器 管理 系统 或 调用 插件 ) 的 版 本 。 
容器 ID ， 如 上 所 述 。 

网 络 命名 空间 路 径 ， 如 上 定义 。 

网 络 配置 ， 如 上 所 述 。 

额外 的 参数 ， 如 上 所 述 。 

上 面 定义 的 容器 内 的 接口 的 名 称 。 


所 有 参数 应 与 传递 给 相应 的 添加 操作 的 参数 相同 。 
删除 操作 应 释放 配置 的 网 络 中 提供 的 containerid 拥 有 的 所 有 资源 。 


报告 版 本 


d 


参数 : 无 。 
结果 : 插件 支持 的 CNI 规 范 版 本 信息 。 


"cniVersion" :20.3.17，// 此 输出 使 用 的 CNI 规 范 的 版 本 
“supportedVersions” : :[170.1.0"* 9.2.0" * "8.29.0" * *Q,9. 1" ] // 此 插件 
支持 的 CNI 规 范 版 本 列表 


} 


CNI 插 件 的 详细 说 明 请 参考 : CNI SPEC e 


IP 分 配 


作为 容器 网 络 管理 的 一 部 分 ，CNI 插 件 需 要 为 接口 分 配 (并 维护 ) IP 地 址 ， 并 安装 
与 该 接口 相关 的 所 有 必要 路 由 。 这 给 了 CNI 插 件 很 大 的 灵活 性 ， 但 也 给 它 带 来 了 很 
大 的 负担 。 众 多 的 CNI 插 件 需要 编写 相同 的 代码 来 支持 用 户 需 要 的 多 种 |P 管 理 方案 
(例如 dhcp、host-local) ° 


为 了 减轻 负担 ， 使 IP 管 理 策略 与 CNI 插 件 类 型 解 厢 ， 我 们 定义 了 IP 地 址 管理 插件 
(IPAM 插 件 ) 。CNI 插 件 的 职责 是 在 执行 时 恰当 地 调用 IPAM 插 件 。1IPAM 插 件 必 须 
确定 接口 IP/subnet， 网 关 和 路 由 ， 并 将 此 信息 返回 到 “ 主 " 插 件 来 应 用 配置 。|IPAM 
插件 可 以 通过 协议 (例如 dhcp) 、 存 储 在 本 地 文件 系统 上 的 数据 、 网 络 配置 文件 
的 “ipam” 部 分 或 上 述 的 组 合 来 获得 信息 。 


IPAM 插 件 


像 CNI 揪 件 一 样 ， 调 用 IPAM 插 件 的 可 执行 文件 。 可 执行 文件 位 于 预定 义 的 路 径 列 表 
中 ， 通 过 CNI PATH 指示 给 CNI 插 件 。1IPAM 插 件 必 须 接 收 所 有 传 入 CNI 插 件 的 相 
同 环境 变量 。 就 像 CNI 插 件 一 样 ，IPAM 插 件 通过 stdin 接 收 网 络 配置 。 


可 用 插件 


Main : 接口 创建 


e bridge : 创建 网 桥 ， 并 添加 主机 和 容器 到 该 网 桥 

。ipvlan : 在 容 颈 中 添加 一 个 ipvlan 接 口 

e loopback : 创建 一 个 回环 接口 

e macvlan : 创建 一 个 新 的 MAC 地 址 ， 将 所 有 的 流量 转发 到 容器 
e ptp : 创建 veth 对 

e vlan : 分 配 一 个 vlan 设备 


IPAM : IP 地 址 分 配 


e dhcp: 在 主机 上 运行 守护 程序 ， 代 表 容 器 发 出 DHCP 请 求 
e host-local : 维护 分 配 IP 的 本 地 数据 库 


Meta : 其 它 插件 


e flannel : 根据 flannel 的 配置 文件 创建 接口 

e tuning : 调整 现 有 接口 的 sysctl 参 数 

e portmap : 一 个 基于 iptables 的 portmapping 揪 件 。 将 端口 从 主机 的 地 址 空间 映 
射 到 容器 。 


参考 


e https://github.com/containernetworking/cni 

e https://github.com/containernetworking/plugins 
e Container Networking Interface Specification 

e CNI Extension conventions 
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储 接口 ) 


CSI RÈ RAKO > CSI 试图 建立 一 个 行业 标准 接口 的 规范 ， 借 助 CSI 容器 编 
HEAR (CO) 可 以 将 任意 存储 系统 暴露 给 自己 的 容器 工作 人 负载。 有关 详细 信息 ， 


请 查看 设计 方案 。 


csi SKA — $t in-tree ( 即 跟 其 它 存储 插件 在 同一 个 代码 路 径 下 ， 随 
Kubernetes 的 代码 同时 编译 的 ) 的 CSI 卷 插件 ， 用 于 Pod 与 在 同一 节点 上 运行 的 
外 部 CSI 卷 驱动 程序 交互 。 部 署 CS| 兼容 卷 驱动 后 ， 用 户 可 以 使 用 csi 作为 卷 
类 型 来 挂 载 驱动 提供 的 存储 。 


CSI 持久 化 卷 支持 是 在 Kubernetes v1.9 中 引入 的 ， 作 为 一 个 alpha 特性 ， 必 须 由 
集群 管理 员 明 确 启 用 。 换 名 话说 ， 集 群 管理 员 需 要 在 apiserver ` controller- 
manager 和 kubelet 组 件 的 “ --feature-gates = ”标志 中 加 上 


" CSIPersistentVolume = true ”° 
CSI 持久 化 卷 具 有 以 下 字段 可 供用 户 指定 : 


e driver :一 个 字符 囊 值 ， 指定 要 使 用 的 卷 驱动 程序 的 名 称 。 必 须 少 于 63 个 
字符 ， 并 以 一 个 字符 开头 。 了 驱动 程 序 名 称 可 以 包 念 “。”、“-”、“ ”或 数字 。 

e volumeHandle : 一 个 字符 串 值 ， 唯 一 标识 从 CSI 卷 插件 的 
CreateVolume 调用 返回 的 卷 名 。 随 后 在 卷 驱 动 程序 的 所 有 后 续 调 用 中 使 用 
卷 名 本 来 引用 该 卷 。 

e readonly :一 个 可 选 的 布尔 值 ， 指示 卷 是 否 被 发 布 为 只 读 。 默 认 是 false。 


使 用 说 明 
下 面 将 介绍 如 何 使 用 CSI 。 


动态 配置 


可 以 通过 为 CSI 创建 插件 StorageClass 来 支持 动态 配置 的 CSI Storage 插件 局 
用 自动 创建 /删除 。 


例如 ， 以 下 StorageClass 允许 通过 名 为 com.example.team/csi-driver 的 
CSI Volume Plugin 动态 创建 “fast-storage” Volume ° 


kind: StorageClass 
apiVersion: storage.k8s.io/vi 
metadata: 
name: fast-storage 
provisioner: com.example.team/csi-driver 
parameters: 
type: pd-ssd 


要 触发 动态 配置 ， 请 创建 一 个 PersistentvolumeClaim 对 象 。 例 如 ， 下 面 的 
PersistentVolumeClaim 可 以 使 用 上 面 的 StorageClass 触发 动态 配置 。 


apiVersion: vi 
kind: PersistentVolumeClaim 
metadata: 

name: my-request-for-storage 
spec: 

accessModes: 

- ReadwriteOnce 

resources: 

requests: 
storage: 5Gi 
storageClassName: fast-storage 


4 a A413 Volume 时 ， 通 过 CreateVolume 调用 ， 将 参数 type: pd-ssd 传递 

给 CSI 插件 com.example.team/csi-driver 。 作 为 响应 ， 外 部 Volume 插件 会 

创建 一 个 新 Volume， 然 后 自动 创建 一 个 PersistentVolume 对 象 来 对 应 前 面 的 

PVC 。 然 后 ，Kubernetes 会 将 新 的 PersistentVolume 对 象 绑 定 到 
PersistentVolumeClaim ， 使 其 可 以 使 用 。 


如 果 fast-storage StorageClass 被 标记 为 默认 值 ， 则 不 需要 在 
PersistentVolumeClaim 中 包含 StorageClassName， 它 将 被 默认 使 用 。 


预 配置 Volume 


您 可 以 通过 手动 创建 一 个 PersistentVolume 对 象 来 展示 现 有 Volumes? Mine 
Kubernetes F Ai AG Volume » B40 » RRA T 
com.example.team/csi-driver 这 个 CSI 插件 的 existingVolumeName 


Volume 


apiVersion: v1 
kind: PersistentVolume 
metadata: 

name: my-manually-created-pv 
spec: 

Capacity: 

storage: 5Gi 
accessModes: 

- ReadwriteOnce 
persistentVolumeReclaimPolicy: Retain 
csi: 

driver: com.example.team/csi-driver 

volumeHandle: existingVolumeName 

readOnly: false 


附 者 和 挂 载 


您 可 以 在 任何 的 pod 或 者 pod 的 template 中 引用 绑 定 到 CSI volume 上 的 


PersistentVolumeClaim ° 


kind: Pod 
apiVersion: vi 
metadata: 
name: my-pod 
spec: 
containers: 
- name: my-frontend 
image: dockerfile/nginx 
volumeMounts: 
- mountPath: "/var/www/html" 
name: my-csi-volume 
volumes: 
- name: my-csi-volume 
persistentVolumeClaim: 
claimName: my-request-for-storage 


当 一 个 引用 了 CSI Volume 的 pod 被 调度 时 ，Kubernetes 将 针对 外 部 CSI 插件 进 
行 相应 的 操作 ， 以 确保 特定 的 Volume 被 attached ` mounted ， 并 且 能 被 pod 中 的 
容器 使 用 。 


关于 CSI 实现 的 详细 信息 请 参考 设计 文档 。 


创建 CSI 驱动 


Kubernetes 尽 可 能 少 地 指定 CSI Volume 驱动 程序 的 打包 和 部 署 规范 。 这 里 记录 了 
在 Kubernetes 上 部 署 CSI Volume 驱动 程序 的 最 低 要 求 。 


are 含 概 述 部 分 ， 提 供 Kubernetes 上 部 署 任意 容器 化 CSI 驱动 
序 的 建议 机 制 。 存 储 提供 s 这 个 机 制 来 简化 Kubernetes LR 3 X, CSI 
兼容 Volume 驱动 程序 的 部 署 。 


作为 推荐 部 署 的 一 部 分 ，Kubernetes 团队 提供 以 下 sidecar (辅助 ) 容器 : 
e External-attacher 


可 监听 Kubernetes VolumeAttachment 对 象 并 触发 ControllerPublish 和 
ControllerUnPublish 操作 的 sidecar 容器 ， 通 过 CSI endpoint 触发 ; 


e External-provisioner 


监听 Kubernetes PersistentVolumeClaim * 4% sidecar 容器 ， 并 触发 对 CSI 
端点 的 CreateVolume feDeleteVolume 操作 ; 


e Driver-registrar 


使 用 Kubelet (将 来 ) 注册 CSI 驱动 程序 的 sidecar 容器 ， 并 将 NodeId 
(通过 GetNodeID 调用 检索 到 CSI endpoint) 添加 到 Kubernetes Node 
API 对 象 的 annotation 里 面 。 


存储 供应 商 完全 可 以 使 用 这 些 组 件 来 为 其 插件 构建 Kubernetes Deployment > F) 84 
让 它们 的 CSI 驱动 程序 完全 意识 不 到 Kubernetes 的 存在 。 


另外 CSI 驱动 完全 是 由 第 三 方 存储 供应 商 自 己 维护 的 ， 在 kubernetes 1.9 版 本 中 
CSI 还 处 于 alpha 版 本 。 


e Introducing Container Storage Interface (CSI) Alpha for Kubernetes 


e Container Storage Interface (CSI) 
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我 们 当初 使 用 kubernetes-vagrant-centos-cluster 安 装 了 拥有 三 个 节点 的 kubernetes 
集群 ， 节 点 的 状态 如 下 所 述 。 


[root@node1 ~]# kubectl get nodes -o wide 


NAME STATUS ROLES AGE VERSION EXTERNAL - IP 
OS- IMAGE KERNEL - VERSION CONTAINER-R 
UNTIME 

node1 Ready <none> 2d v1.9.1 «none» 


CentOS Linux 7 (Core) 3.10.0-693.11.6.e17.x86 64 docker://1. 
12.6 

node2 Ready <none> 2d v1.9.1 <none> 

CentOS Linux 7 (Core) 3.10.0-693.11.6.e17.x86_64 docker://1. 
12.6 

node3 Ready <none> 2d v1.9.1 «none» 

CentOS Linux 7 (Core) 3.10.0-693.11.6.e17.x86 64 docker://1. 
12.6 


当前 Kubernetes 集 群 中 运行 的 所 有 Pod 信 息 : 


[root@node1 ~]# kubectl get pods --all-namespaces -o wide 
NAMESPACE NAME 


READY STATUS RESTARTS AGE IP NODE 
kube-system | coredns-5984fb8cbb-sjqv9 

1/1 Running 0 1h 172.33.68.2 nodei 
kube-system coredns-5984fb8cbb-tkfrc 

1/1 Running 1 1h 172.33.96.3 node3 
kube-system heapster-v1.5.0-684c7f9488-z6sdz 

4/4 Running 0 1h 172.33.31.3 node2 
kube-system kubernetes-dashboard-6b66b8b96c -mnm2c 

1/1 Running 0 1h 172.33.31.2 node2 
kube-system monitoring-influxdb-grafana-v4-54b7854697-tw9cd 
2/2 Running 2 1h 172.33.96.2 node3 


当前 etcd 中 的 注册 的 宿主 机 的 pod 地 址 网 段 信息 : 


[root@node1 ~]# etcdctl ls /kube-centos/network/subnets 
/kube-centos/network/subnets/172.33.68.0-24 
/kube-centos/network/subnets/172.33.31.0-24 
/kube-centos/network/subnets/172.33.96.0-24 


而 每 个 node 上 的 Pod 子 网 是 根据 我 们 在 安装 flannel 时 配置 来 划分 的 ， 在 etcd 中 查看 
该 配置 : 


[root@node1 ~]# etcdctl get /kube-centos/network/config 
("Network":"172.33.0.0/16", "SubnetLen":24, "Backend": {"Type": "hos 
t-gw"}} 

我 们 知道 Kubernetes 集 群 内 部 存在 三 类 IP， 分 别 是 : 


e Node IP : 宿主 机 的 IP 地 址 
e Pod IP : 使 用 网 络 插 件 创建 的 IP (如 flannel) ， 使 跨 主 机 的 Pod 可 以 互通 
e Cluster IP : 虚拟 |P， 通 过 iptables 规 则 访问 服务 


在 安装 node 节 点 的 时 候 ， 节 点 上 的 进程 是 按照 flannel| -> docker -> kubelet -> kube- 
proxy 的 顺序 启动 的 ， 我 们 下 面 也 会 按照 该 顺序 来 讲解 ，flannel 的 网 络 划 分 和 如 何 与 
docker 交 互 ， 如 何 通 过 iptables 访 问 service。 


Flannel 


Flannel 是 作为 一 个 二 进 制 文件 的 方式 部 署 在 每 个 node 上 ， 主 要 实现 两 个 功能 : 


e 为 每 个 node 分 配 subnet， 容 器 将 自动 从 该 子 网 中 获取 IP 地 址 
e 当 有 node 加 入 到 网 络 中 时 ， 为 每 个 node 增 加 路 由 配置 


下 面 是 使 用 host-gw backend 的 flannel 网 络 架 构图 : 


Kubernetes 中 的 网 络 解析 以 flanne| 为 例 





NODE 1 


192.168.0.100 


192.168.0.200 


图 片 -flannel 网 络 架构 (图 片 来 自 openshift) 


注意 : 以 上 IP 非 本 示例 中 的 IJP， 但 是 不 影响 读者 理解 。 


Node1 上 的 flannel 配 置 如 下 : 
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[root@node1 ~]# cat /usr/lib/systemd/system/flanneld.service 
[Unit] 

Description-Flanneld overlay address etcd agent 
After-network.target 

After-network-online.target 

Wants-network-online.target 

After=etcd.service 

Before=docker.service 


[Service ] 

Type=notify 

EnvironmentFile=/etc/sysconfig/flanneld 
EnvironmentFile=-/etc/sysconfig/docker -network 
ExecStart=/usr/bin/flanneld-start $FLANNEL_OPTIONS 
ExecStartPost=/usr/libexec/flannel/mk-docker-opts.sh -k DOCKER_N 
ETWORK_OPTIONS -d /run/flannel/docker 

Restart=on-failure 


[Install] 
WantedBy=multi-user.target 
RequiredBy-docker.service 


其 中 有 两 个 环境 变量 文件 的 配置 如 下 : 


[root@node1 ~]# cat /etc/sysconfig/flanneld 

# Flanneld configuration options 
FLANNEL_ETCD_ENDPOINTS="http://172.17.8.101:2379" 
FLANNEL_ETCD_PREFIX="/kube-centos/network" 
FLANNEL_OPTIONS="-iface=eth2" 


上 面 的 配置 文件 仅 供 flanneld 使 用 。 


[root@node1 ~]# cat /etc/sysconfig/docker-network 
# /etc/sysconfig/docker-network 
DOCKER_NETWORK_OPTIONS= 


还 有 一 个 ExecStartPost-/usr/libexec/flannel/mk-docker-opts.sh -k 
DOCKER_NETWORK_OPTIONS -d /run/flannel/docker ， 其 中 

的 /usr/libexec/flannel/mk-docker-opts.sh 脚本 是 在 flanneld 启 动 后 运行 ， 
将 会 生成 两 个 环境 变量 配置 文件 : 


e /run/flannel/docker 
e /run/flannel/subnet.env 


我 们 再 来 看 下 /run/flannel/docker 的 配置 。 


[root@node1 ~]# cat /run/flannel/docker 
DOCKER_OPT_BIP="- -bip=172.33.68.1/24" 
DOCKER_OPT_IPMASQ="- -ip-masq=true" 


DOCKER_OPT_MTU=" - -mtu=1500" 
DOCKER NETWORK OPTIONS-" - -bip=172.33.68.1/24 --ip-masq=true --m 


tu=1500" 
如 果 你 使 用 systemctl 命令 先 启 动 flannel 后 启动 docker 的 话 ，docker 将 会 读 取 以 
上 环境 变量 。 


我 们 再 来 看 下 /run/flannel/subnet.env 的 配置 。 


[root@node1 ~]# cat /run/flannel/subnet.env 
FLANNEL_NETWORK=172.33.0.0/16 
FLANNEL_SUBNET=172.33.68.1/24 
FLANNEL_MTU=1500 

FLANNEL_IPMASQ=false 


以 上 环境 变量 是 flannel 向 etcd 中 注册 的 。 


Docker 


Node1 的 docker 配 置 如 下 : 


[root@node1 ~]# cat /usr/lib/systemd/system/docker.service 
[Unit] 

Description-Docker Application Container Engine 
Documentation-http://docs.docker.com 

After-network.target rhel-push-plugin.socket registries.service 
Wants-docker-storage-setup.service 
Requires-docker-cleanup.timer 


[Service] 
Type-notify 
NotifyAccess-all 
EnvironmentFile--/run/containers/registries.conf 
EnvironmentFile--/etc/sysconfig/docker 
EnvironmentFile--/etc/sysconfig/docker-storage 
EnvironmentFile--/etc/sysconfig/docker-network 
Environment-GOTRACEBACK-crash 
Environment-DOCKER HTTP HOST COMPAT-1 
Environment-PATH-/usr/libexec/docker:/usr/bin:/usr/sbin 
ExecStart-/usr/bin/dockerd-current \ 
--add-runtime docker-runc-/usr/libexec/docker/docker-r 
unc-current \ 
--default-runtime=docker-runc \ 
--exec-opt native.cgroupdriver=systemd \ 
--userland-proxy-path=/usr/libexec/docker/docker - proxy 
-current \ 
S$OPTIONS \ 
$DOCKER_STORAGE_OPTIONS \ 
$DOCKER_NETWORK_OPTIONS \ 
$ADD REGISTRY \ 
S$BLOCK REGISTRY \ 
$INSECURE_REGISTRY\ 
$REGISTRIES 
ExecReload-/bin/kill -s HUP $MAINPID 
LimitNOFILE-1048576 
LimitNPROC-1048576 
LimitCORE-infinity 
TimeoutStartSec=0 
Restart=on-abnormal 
MountFlags=slave 
KillMode-process 





[Install] 
WantedBy-multi-user.target 


查看 Node1 上 的 docker 启 动 参数 : 


[root@node1 ~]# systemctl status -1 docker 
e docker.service - Docker Application Container Engine 
Loaded: loaded (/usr/lib/systemd/system/docker.service; enabl 
ed; vendor preset: disabled) 
Drop-In: /usr/lib/systemd/system/docker.service.d 
L—flannel.conf 
Active: active (running) since Fri 2018-02-02 22:52:43 CST; 2 
h 28min ago 
Docs: http://docs.docker.com 
Main PID: 4334 (dockerd-current) 
CGroup: /system.slice/docker.service 
* 4334 /usr/bin/dockerd-current --add-runtime docker- 
runc-/usr/libexec/docker/docker-runc-current --default-runtime-d 
OCker-runc --exec-opt native.cgroupdriver-systemd --userland-pro 
xy-path-/usr/libexec/docker/docker-proxy-current --selinux-enabl 
ed --log-driver-journald --signature-verification-false --bip-17 
2.33.68.1/24 --ip-masq-true --mtu-1500 


我 们 可 以 看 到 在 docker 在 尼 动 时 有 如 下 参数 : --bip=172.33.68.1/24 --ip- 
masq-true --mtu-1500 。 上 述 参数 flannel 启 动 时 运行 的 脚本 生成 的 ， 通 过 环境 变 
量 传递 过 来 的 。 


我 们 查看 下 node1 宿 主机 上 的 网 络 接口 : 


[root@node1 ~]# ip addr 
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKN 
OWN qlen 1 
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 
inet 127.0.0.1/8 scope host lo 
valid lft forever preferred_lft forever 
inet6 ::1/128 scope host 
valid lft forever preferred lft forever 
2: ethO: «BROADCAST, MULTICAST, UP, LOWER UP» mtu 1500 qdisc pfifo 
fast state UP qlen 1000 
link/ether 52:54:00:00:57:32 brd ff:ff:ff:ff:ff:ff 
inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic ethO 
valid lft 85095sec preferred lft 85095sec 
inet6 fe80::5054:ff:fe00:5732/64 scope link 
valid lft forever preferred lft forever 
3: eth1: «BROADCAST, MULTICAST, UP, LOWER UP» mtu 1500 qdisc pfifo 
fast state UP qlen 1000 
link/ether 08:00:27:7b:0f:b1 brd ff:ff:ff:ff:ff:ff 
inet 172.17.8.101/24 brd 172.17.8.255 scope global eth1 
valid lft forever preferred lft forever 
4: eth2: «BROADCAST, MULTICAST, UP, LOWER UP» mtu 1500 qdisc pfifo 
fast state UP qlen 1000 
link/ether 08:00:27:ef:25:06 brd ff:ff:ff:ff:ff:ff 
inet 172.30.113.231/21 brd 172.30.119.255 scope global dynam 
ic eth2 
valid lft 85096sec preferred lft 85096sec 
inet6 fe80::a00:27ff:feef:2506/64 scope link 
valid lft forever preferred lft forever 
5: docker0: «BROADCAST, MULTICAST, UP, LOWER UP» mtu 1500 qdisc noq 
ueue state UP 
link/ether 02:42:d0:ae:80:ea brd ff:ff:ff:ff:ff:ff 
inet 172.33.68.1/24 scope global dockerO 
valid lft forever preferred lft forever 
inet6 fe80::42:dOff:feae:80ea/64 scope link 
valid lft forever preferred lft forever 
7: veth295bef2@if6: «BROADCAST, MULTICAST, UP, LOWER UP» mtu 1500 q 
disc noqueue master dockerO state UP 
link/ether 6a:72:d7:9f:29:19 brd ff:ff:ff:ff:ff:ff link-netn 
sid 0 
inet6 fe80::6872:d7ff:fe9f:2919/64 scope link 
valid lft forever preferred lft forever 


我 们 分 类 来 解释 下 该 虚拟 机 中 的 网 络 接口 。 


e lo: 回环 网 络 ，127.0.0.1 

e eth0 : NAT 网 络 ， 虚 拟 机 创建 时 自动 分 配 ， 仅 可 以 在 几 台 虚拟 机 之 间 访 问 

e eth1 : bridge 网 络 ， 使 用 vagrant 分 配给 虚拟 机 的 地 址 ， 虚 拟 机 之 间 和 本 地 电脑 
都 可 以 访问 

。 eth2 : bridge 网 络 ， 使 用 DHCP 分 配 ， 用 于 访问 互联 网 的 网 卡 


e dockerO : bridge 网 络 ，docker 默 认 使 用 的 网 卡 ， 作 为 该 节点 上 所 有 容器 的 虚拟 
交换 机 

e veth295bef2@if6 : veth pair， 和 连接 docker0 和 Pod 中 的 容器 。veth pair 可 以 理 
解 为 使 用 网 线 连 接 好 的 两 个 接口 ， 把 两 个 端口 放 到 两 个 hamespace 中 ， 那 么 这 
两 个 hamespace 就 能 打通 。 参 考 |inux 网 络 虚 拟 化 : network namespace fi 
ds 


我 们 再 看 下 该 节点 的 docker 上 有 哪些 网 络 。 


[root@node1 ~]# docker network ls 


NETWORK ID NAME DRIVER SCOP 
E bridge bridge loca 
T" host host loca 
ee none null loca 
1 


再 检查 下 bridge 网 络 940bb75e653b 的 信息 。 
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[root@node1 ~]# docker network inspect 940bb75e653b 
[ 
{ 
"Name": "bridge", 


"Id": "940bb75e653bfa10dab4cce8813c2b3ce17501e4e4935f7dc 
13805a61b732d2c", 


"Scope": "local", 
"Driver": "bridge", 
"EnableIPv6": false, 
"IPAM": { 

"Driver": "default", 

"Options": null, 

"Config": [ 

{ 


"Subnet": '"172,.39.58,17/24", 
"Gateway": "172.33.68.1" 


] 
tr 
"Internal": false, 
"Containers": { 
"944d4aa660e30e1be9a18d30c9dcfa3b0504d1e5dbd00f3004b 
76582f1c9a85b": ( 
"Name": "k8s POD coredns-5984fb8cbb-sjqv9 kube-s 
ystem c5a2e959-082a-11e8-b4cd-525400005732 0", 
"EndpointID": "73974d7282e464fc4ec5756d6b328df 889 
cdf46134dbbe3753517e175d3844a85", 
"MacAddress": "02:42:ac:21:44:02", 
"IPv4Address": "172.33.68.2/24", 


"IPveAddress": "" 
} 
ty 
"Options"; { 
"com.docker.network.bridge.default_bridge": "true", 
"com.docker.network.bridge.enable_icc": "true", 
"com.docker.network.bridge.enable ip masquerade": "t 
rue", 
"com.docker.network.bridge.host binding ipv4": "0.0. 
0.0", 
"com.docker.network.bridge.name": "dockerO", 
"com.docker.network.driver.mtu": "1500" 
ty 
"Labels": {} 
} 
] 


我 们 可 以 看 到 该 网 络 中 的 Config 与 docker 的 启动 配置 相符 。 


e 


Node1 上 运行 的 容器 : 
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[root@node1 ~]# docker ps 


CONTAINER ID IMAGE 
COMMAND 
CREATED STATUS PORTS 
NAMES 
a37407a234dd docker.io/coredns/corednsQsha256:adf2e5b4504 
efo9ffa43f16010bd064273338759e92f6f616dd159115748799bc "/coredn 
S -conf /etc/" About an hour ago Up About an hour 


k8s coredns coredns-5984fb8cbb-sjqv9 kube-system c5 
a2e959-082a-11e8-b4cd-525400005732 0 
944d4aa660e3 docker.io/openshift/origin-pod 
"/usr/bi 
n/pod" About an hour ago Up About an hour 
k8s. POD coredns-5984fb8cbb-sjqv9 kube-system c5a2e9 
59-082a-11e8-b4cd-525400005732 0 


我 们 可 以 看 到 当前 已 经 有 2 个 容器 在 运行 。 


Node1 上 的 路 由 信息 : 


[root@node1 ~]# route -n 

Kernel IP routing table 

Destination Gateway Genmask Flags Metric Ref 

Use Iface 

0.0.0.0 10.0.2.2 0.0.0.0 UG 100 0 
© etho 

0.0.0.0 172.30.116.1 0.0.0.0 UG 101 0 
0 eth2 

10.0.2.0 0.0.0.0 255.255.255.0 U 100 0 
© etho 

172.17.8.0 0.0.0.0 255.255.255.0 U 100 0 
© ethi 

172.30.112.0 0.0.0.0 255.255.248.0 U 100 0 
0 eth2 

172.33.68.0 0.0.0.0 255.255.255.0 U 0 0 
© dockerg 

172.33.96.0 172.30.118.65 255.255.255.0 UG 0 0 
0 eth2 


以 上 路 由 信 息 是 由 flannel 添 加 的 ， 当 有 新 的 节 点 加 入 到 Kubernetes 集 群 中 后 " 每 个 
节点 上 的 路 由 表 都 将 增加 。 


我 们 在 node 上 来 traceroute 下 node3 上 的 coredns-5984fb8cbb-tkfrc 容器 ， 
其 IP 地 址 是 172.33.96.3 ， 看 看 其 路 由 信息 。 


[root@node1 ~]# traceroute 172.33.96.3 

traceroute to 172.33.96.3 (172.33.96.3), 30 hops max, 60 byte pa 
ckets 

1 172.30.118.65 (172.30.118.65) 20.518 ms 0.367 ms 0.398 ms 
2 172.33.96.3 (172.33.96.3) 0.451 ms 0.352 ms 0.223 ms 


我 们 看 到 路 由 直接 经 过 node3 的 公 网 IP 后 就 到 达 了 node3 节 点 上 的 Pod ° 


Node1 的 iptables 信 息 : 


[root@node1 ~]# iptables -L 
Chain INPUT (policy ACCEPT) 


target prot opt source destination 
KUBE-FIREWALL all -- anywhere anywhere 
KUBE-SERVICES all -- anywhere anywhere 


/* kubernetes service portals */ 


Chain FORWARD (policy ACCEPT) 


target prot opt source destination 
KUBE-FORWARD all -- anywhere anywhere 

/* kubernetes forward rules */ 

DOCKER-ISOLATION all -- anywhere anywhere 
DOCKER all -- anywhere anywhere 
ACCEPT all -- anywhere anywhere ct 
state RELATED, ESTABLISHED 
ACCEPT all -- anywhere anywhere 
ACCEPT all -- anywhere anywhere 

Chain OUTPUT (policy ACCEPT) 

target prot opt source destination 
KUBE-FIREWALL all -- anywhere anywhere 
KUBE-SERVICES all -- anywhere anywhere 


/* kubernetes service portals */ 


Chain DOCKER (1 references) 
target prot opt source destination 


Chain DOCKER-ISOLATION (1 references) 


target prot opt source destination 

RETURN all -- anywhere anywhere 

Chain KUBE-FIREWALL (2 references) 

target prot opt source destination 

DROP all -- anywhere anywhere /* 


kubernetes firewall for dropping marked packets */ mark match 0 
x8000/0x8000 


Chain KUBE-FORWARD (1 references) 


target prot opt source destination 

ACCEPT all -- anywhere anywhere /* 
kubernetes forwarding rules */ mark match 0x4000/0x4000 

ACCEPT all -- 10.254.0.0/16 anywhere /* 


kubernetes forwarding conntrack pod source rule */ ctstate RELA 
TED, ESTABLISHED 
ACCEPT all -- anywhere 10.254.0.0/16 /* 
kubernetes forwarding conntrack pod destination rule */ ctstate 
RELATED, ESTABLISHED 


Chain KUBE-SERVICES (2 references) 
target prot opt source destination 


从 上 面 的 iptables 中 可 以 看 到 注入 了 很 多 Kuberentes service JL 9] » HAF 
iptables 规则 获取 更 多 详细 信息 。 


e coreos/flannel - github.com 

e linux 网 络 虚 拟 化 : network namespace 简介 
e Linux 虚 拟 网 络 设 备 之 veth 

e iptables 规则 

e flannel host-gw network 

e flannel - openshift.com 
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概念 


Calico 创建 和 管理 一 个 扁平 的 三 层 网 络 (不 需要 overlay)， 每 个 容器 会 分 配 一 个 可 路 
由 的 ip。 由 于 通信 时 不 需要 解 包 和 封包 ， 网 络 性 能 损耗 小 ， 易 于 排查 ， 且 易于 水 平 
扩展 。 

小 规模 部 署 时 可 以 通过 bgp client 直 接 互联 ， 大 规模 下 可 通过 指定 的 BGP route 
reflector 来 完成 ， 这 样 保证 所 有 的 数据 流量 都 是 通过 |P 路 由 的 方式 完成 互联 的 。 
Calico 基 于 iptables 还 提供 了 丰富 而 灵活 的 网 络 Policy， 保 证 通过 各 个 节点 上 的 ACLs 
来 提供 Workload 的 多 租户 隔离 、 安 全 组 以 及 其 他 可 达 性 限制 等 功能 。 


Calico% 4# 








图 片 - CRIRW-A A X B https:/www.jianshu.com/p/f0177b84de66 


calico i. € t Felix,etcd,BGP client,BGP Route Reflector 组 成 。 


e Etcd : 负责 存储 网 络 信息 
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e BGP client: 负责 将 Felix 配 置 的 路 由 信息 分 发 neues 点 

e Felix : Calico phi ， 每 个 节点 都 需要 运行 ， 主 要 负责 配置 路 由 、 配 置 ACLs、 
报告 状态 

e BGP Route Reflector : 大 规模 部 署 时 需要 用 到 ， 作 为 BGP client 的 中 心 连接 
点 ， 可 以 避免 每 个 节点 互联 


E 


mkdir /etc/cni/net.d/ 


kubectl apply -f https://docs.projectcalico.org/v3.0/getting-sta 
rted/kubernetes/installation/rbac.yaml 


wget https://docs.projectcalico.org/v3.0/getting-started/kuberne 
tes/installation/hosted/calico.yaml 


修改 etcd_endpoints 的 值 和 默认 的 192.168.0.0/16( 不 能 和 已 有 网 段 冲突 ) 
kubectl apply -f calico.yaml 


wget https://github.com/projectcalico/calicoctl/releases/downlo 
ad/v2.0.0/calicoctl 


mv calicoctl /usr/loca/bin && chmod +x /usr/local/bin/calicoctl 
calicoctl get ippool 


calicoctl get node 


e 部署 
e calicoctlr + 
e RH 
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Objects 


以 下 列举 的 内 容 都 是 kubernetes 中 的 Object， 这 些 对 象 都 可 以 在 yaml 文件 中 作为 
一 种 API 类 型 来 配置 。 


e Pod 

e Node 

e Namespace 

e Service 

e Volume 

e PersistentVolume 

e Deployment 

e Secret 

e StatefulSet 

e DaemonSet 

e ServiceAccount 

e ReplicationController 
e ReplicaSet 

e Job 

e CronJob 

e SecurityContext 

e ResourceQuota 

e LimitRange 

e HorizontalPodAutoscaling 
e Ingress 

e ConfigMap 

e Label 

e ThirdPartyResources 


我 将 它们 简单 的 分 类 为 以 下 几 种 资源 对 象 : 


A 名 称 


78. Pod ` ReplicaSet ` ReplicationController ` Deployment ` StatefulSet ` 
对 DaemonSet ` Job ` CronJob ` HorizontalPodAutoscaling 


置 Node ` Namespace ` Service ` Secret ^ ConfigMap ^ Ingress ` Label ` 
对 ThirdPartyResource、ServiceAccount 


Volume ^ Persistent Volume 


SecurityContext ` ResourceQuota ` LimitRange 


理解 kubernetes 中 的 对 象 


在 Kubernetes 系统 中 ，Kubernetes 对 象 是 持久 化 的 条 目 。Kubernetes 使 用 这 些 
条 目 去 表示 整个 集群 的 状态 。 特 别 地 ， 它 们 描述 了 如 下 信息 : 


e 什么 容器 化 应 用 在 运行 (以 及 在 哪个 Node 上 ) 
e 可 以 被 应 用 使 用 的 资源 
e 关于 应 用 如 何 表现 的 策略 ， 比 如 重启 策略 、 升 级 策略 ， 以 及 容错 策略 


Kubernetes 对 象 是 “目标 性 记录 ”一 一 一 旦 创建 对 象 ，Kubernetes 系统 将 持续 工作 
以 确保 对 象 存在 。 通 过 创建 对 象 ， 可 以 有 效 地 告知 Kubernetes 系统 ， 所 需要 的 集 
群 工作 负载 看 起 来 是 什么 样子 的 ， 这 就 是 Kubernetes 集群 的 期 望 状态 。 


与 Kubernetes 对 象 工 作 — 是否 创建 、 修 改 ， 或 者 删除 — 需要 使 用 
Kubernetes API ° 34€] kubectl 命令 行 接口 时 ， 比 如 ，CLI 会 使 用 必要 的 
Kubernetes API 调用 ， 也 可 以 在 程序 中 直接 使 用 Kubernetes API。 为 了 实现 该 目 
标 ，Kubernetes 当前 提供 了 一 个 golang 客户 端 库 ， 其 它 语言 库 (例如 
Python) 也 正在 开发 中 。 


xt 4 Spec 与 状态 


每 个 Kubernetes SRASAPREHHREFRM: CNA TEA : 对 象 
spec 和 *1 % status ° spec 必须 提供 ， 它 描述 了 对 象 的 期 望 状态 希望 对 象 所 
具有 的 特征 。status 描述 了 对 象 的 实际 状态 ， 它 是 由 Kubernetes 系统 提供 和 更 

新 。 在 任何 时 刻 ，Kubernetes 控制 平面 一 直 处 于 活路 状态， 管理 着 对 象 的 实际 状态 
以 与 我 们 所 期 望 的 状态 相 匹 配 。 





例如 ，Kubernetes Deployment 对 象 能 够 表示 运行 在 集群 中 的 应 用 。 当 创建 
Deployment 时 ， 可 能 需要 设置 Deployment 的 spec， 以 指定 该 应 用 需要 有 3 个 副 
本 在 运行 。Kubernetes 系统 读 取 Deployment spec， 启 动 我 们 所 期 望 的 该 应 用 的 3 
个 实例 一 一 更 新 状态 以 与 spec 相 匹 配 。 如 果 那 些 实例 中 有 失败 的 (一 种 状态 变 
更 ) ，Kubernetes 系统 通过 修正 来 响应 spec 和 状态 之 问 的 不 一 致 一 一 这 种 情 
况 ， 局 动 一 个 新 的 实例 来 替换 。 


关于 对 象 spec ^ status 和 metadata 更 多 信息 ， 查 看 Kubernetes API 
Conventions ° 


描述 Kubernetes  % 


当 创 建 Kubernetes 4 AA > 3528 JE DU RAY spec， 用 来 描述 该 对 象 的 期 望 状态 ， 
以 及 关于 对 象 的 一 些 基 本 信息 〈 例 如 ， 名 称 ) 。 当 使 用 Kubernetes API 创建 对 象 
时 (或 者 直接 创建 ， 或 者 基于 kubect1 ) > API 请 求 必 须 在 请 求 体 中 包含 ISON 

格式 的 信息 。 更 常用 的 是 ， 需 要 在 ,yaml 文件 中 为 kubectl 提供 这 些 信 息 。 
kubectl 在 执行 API 请求 时 ， 将 这 些 信息 转换 成 ISON 格式 。 


这 里 有 一 个 .yaml 示例 文件 ， 展 示 了 Kubernetes Deployment 的 必需 字段 和 对 
象 spec : 


apiVersion: apps/vibetai 
kind: Deployment 
metadata: 
name: nginx-deployment 
spec: 
replicas: 3 
template: 
metadata: 
labels: 
app: nginx 
spec: 
containers: 
- name: nginx 
image: nginx:1.7.9 
ports: 
- containerPort: 80 


一 种 创建 Deployment 的 方式 ， 类 似 上 面 使 用 .yaml 文件 ， 是 使 用 kubectl 
命令 行 接口 (CLI) 中 的 kubectl create 命令 ， 传 递 .yaml 作为 参数 。 下 面 


是 一 个 示例 : 


$ kubectl create -f docs/user-guide/nginx-deployment.yaml --reco 
rd 


输出 类 似 如 下 这 样 : 


deployment "nginx-deployment" created 


必需 字段 
在 想 要 创建 的 Kubernetes 对 象 对 应 的 .yaml 文件 中 ， 需 要 配置 如 下 的 字段 : 


e apiversion -创建 该 对 象 所 使 用 的 Kubernetes API 的 版 本 

e kind - 想 要 创建 的 对 象 的 类 型 

e metadata -帮助 识别 对 象 唯 一 性 的 数据 ， 包 括 一 个 name 字符 串 、UID 和 
可 选 的 namespace 


需要 提供 对 象 的 spec 字段。 对 象 spec 的 精确 格式 对 每 个 Kubernetes 对 象 


来 说 是 不 同 的 ， 包 含 了 特定 于 该 对 象 的 瞬 套 字段 。Kubernetes API 参考 能 够 帮助 我 
们 找到 任何 我 们 想 创 建 的 对 象 的 spec 格式 。 


Copyright © jimmysong.io 2017-2018 all right reserved * powered by 
GitbookUpdated at 2018-05-09 14:15:47 


Pod 状 态 与 生命 周期 管 


该 节 将 带领 大 家 了 解 Kubernetes 中 的 基本 概念 ， 尤 其 是 作为 Kubernetes 中 调度 的 最 
基本 单位 Pod 。 


本 节 中 包括 以 下 内 容 : 
ey 解 Pod 的 构 成 


e Pod 的 生命 周期 
e Pod 中 容器 的 启动 顺序 模板 定义 


Kubernetes 中 的 基本 组 件 kube-controller-manager 就 是 用 来 控制 Pod 的 状态 和 
生命 周期 的 ， 在 了 解 各 种 controller 之 前 我 们 有 必要 先 了 解 下 Pod 本 身 和 其 生命 周 
期 。 
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Pod i, 


3? ft Pod 


Pod 是 kubernetes 中 你 可 以 创建 和 部 署 的 最 小 也 是 最 简 的 单位 。 一 个 Pod 代 表 着 集 
群 中 运行 的 一 个 进程 。 


o Oy a Ae Wt ne 
里 容器 如 何 运 行 的 策略 选项 。Pod 代 表 着 部 署 的 一 个 单位 : kubernetes 中 应 用 的 一 
个 实例 ， 可 能 由 一 个 或 者 多 个 容器 组 合 在 一 起 共享 资源 。 


Docker 是 kubernetes 中 最 常用 的 容器 运行 时 ， 但 是 Pod 也 支持 其 他 容器 运行 
时 。 


在 Kubrenetes 集 群 中 Pod 有 如 下 两 种 使 用 方式 : 


e 一 个 Pod 中 运行 一 个 容器 。“ 每 个 Pod 中 一 个 容器 "的 模式 是 最 常见 的 用 法 ; 在 这 
种 使 用 方式 中 ， 你 可 以 把 Pod 想 象 成 是 单个 容器 的 封装 ，kuberentes 管 理 的 是 
Pod 而 不 是 直接 管 o 


e ££ —^ Pod? AH ift 2$ AEE o —^Pod P 4,3 EF] Ep 39 JUS S EE ERR 
合 互相 协作 的 容器 ， i t 享 资源 。 这 些 在 同一 个 Pod 中 的 容器 可 以 互相 
协作 成 为 一 个 service 单 位 一 一 一 个 容器 共享 文件 ， 另 一 个 “sidecar" 容 器 来 更 新 


这 些 文件 。Pod 将 这 些 容 器 的 存储 资源 作为 一 个 实体 来 管理 。 
Kubernetes Blog 有 关于 Pod 用 例 的 详细 信息 ， 查 看 : 


e The Distributed System Toolkit: Patterns for Composite Containers 
e Container Design Patterns 


每 个 Pod 都 是 应 用 的 一 个 实例 。 如 果 你 想 平行 扩展 应 用 的 话 (运行 多 个 实例 ) ， 你 
应 该 运行 多 个 Pod， 每 个 Pod 都 是 一 个 应 用 实例 。 ne ， 这 通常 被 称 为 


replication ° 


Pod 中 如 何 管理 多 个 容器 


Podi 3i, 


Pod 中 可 以 同时 运行 多 个 进程 (作为 容器 运行 ) 协同 工作 。 同 一 个 Pod 中 的 容器 会 
自动 的 分 配 到 同一 个 node 上 。 同 一 个 Pod 中 的 容器 共享 资源 、 网 络 环境 和 依赖 ， 
它们 总 是 被 同 时 调度 9 


Cc ue a g A a 


» 
zt os 
38 
^s 


行 ， he 到 共 pe , n uns 器 ae ie ee 
件 ， 如 下 图 所 示 : 


Content 
Manager 





图 片 - pod diagram 


Pod 中 可 以 共享 两 种 资源 : 网 络 和 存储 。 


网 络 


每 个 Pod 都 会 被 分 配 一 个 唯一 的 IP 地 址 。Pod 中 的 所 有 容器 共享 网 络 空间 ， 包 括 |IP 
地 址 和 端口 。Pod 内 部 的 容器 可 以 使 用 localhost 互相 通信 。Pod 中 的 容器 与 外 
Sei Se NY > AP RHE BRI (例如 使 用 宿主 机 的 端口 映射 ) o 


存储 
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可 以 Pod 指 定 多 个 共享 的 Volume。Pod 中 的 所 有 容器 都 可 以 访问 共享 的 volume © 
Volume 也 可 以 用 来 持久 化 Pod 中 的 存储 资源 ， 以 防 容 器 重启 后 文件 丢失 。 


使 用 Pod 


你 很 少 会 直接 在 kubernetes 中 创建 单个 Pod。 因 为 Pod 的 生命 周期 是 短暂 的 ， 用 后 
即 焚 的 实体 。 当 Pod 被 创建 后 (不论 是 由 你 直接 创建 还 是 被 其 他 Controller) ， 都 会 
被 Kuberentes 调 度 到 集群 的 Node 上 。 直 到 Pod 的 进程 终止 、 被 删 掉 、 因 为 缺少 资源 
而 被 驱逐 、 或 者 Node 故 障 之 前 这 个 Pod 都 会 一 直 保 持 在 那个 Node 上 。 


注意 : 重启 Pod 中 的 容器 跟 重 启 Pod 不 是 一 回 事 。Pod 只 提供 容器 的 运行 环境 


E oe Be 


保持 容器 的 运行 状态 ， 重 启 容器 不 会 造成 Pod 重 启 。 


Pod 不 会 自 念 。 如 果 Pod 运 行 的 Node 故 障 ， 或 者 是 调度 器 本 身 故 障 ， 这 个 Pod 就 会 

被 删除 。 同 样 的 ， 如 果 Pod 所 在 Node 缺 少 资源 或 者 Pod 处 于 维护 状态 ，Pod 也 会 被 

驱逐 。Kubernetes 使 用 更 高 级 的 称 为 Controller 的 抽象 层 ， 来 管理 Pod 实 例 。 虽 然 可 
以 直接 使 用 Pod， 但 是 在 Kubernetes 中 通常 是 使 用 Controller 来 管理 Pod 的 。 


Pod 和 Controller 


Controller 可 以 创建 和 管理 多 个 Pod， 提 供 副 本 管理 、 深 动 升 级 和 集群 级 别 的 自 剑 能 
力 。 例 如 ， 如 果 一 个 Node 故 障 ，Controller 就 能 自动 将 该 节点 上 的 Pod 调 度 到 其 他 
健康 的 Node 上 。 


包含 一 个 或 者 多 个 Pod 的 Controller 示 例 : 


e Deployment 
e StatefulSet 
e DaemonSet 


通常 ，Controller 会 用 你 提供 的 Pod Template 来 创建 相应 的 Pod 。 


Pod Templates 


Pod 模 版 是 包含 了 其 他 object 的 Pod 定 义 ， 例 如 Replication Controllers，Jobs 和 
DaemonSets。Controller 根 据 Pod 模 板 来 创建 实际 的 Pod 。 
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Pod #2 47 


Pod 是 kubernetes 中 可 以 创建 的 最 小 部 署 单元 。 


V1 core 版 本 的 Pod 的 配置 模板 见 Pod template ° 


什么 是 Pod ? 


Pod 就 像 是 骂 豆 英 一 样 ， 它 由 一 个 或 者 多 个 容器 组 成 (例如 Docker 容 器 ) ， 它 们 共 
享 容 器 存储 、 Meque | o doped eodd ， 有 共同 的 运 
AH RSS o ARF 4 


其 中 运行 着 一 
个 或 者 多 个 紧密 耦合 的 应 用 容器 有 容器 之 前 ，i 这 些 应 用 都 是 32 4 于 在 几 个 相同 
的 物理 机 或 者 虚拟 机 上 。 


日 A 4L & » 
《 





























尽管 Kubernetes 支 持 多 种 容器 运行 时 ， 但 是 Docker 依 然 是 最 常用 的 运行 时 环境 ， 我 
TAIT Docker 的 术语 和 规则 来 定义 Pod © 


Pod 中 共享 的 环境 包括 Linux 的 namespace >’ coral: s Ted NUN 隔绝 环境 ， 这 一 点 
跟 Docker 容 器 一 致 。 在 Pod 的 环境 中 ， 每 个 容器 中 可 能 还 有 更 小 的 子 隔离 环境 。 


Pod 中 的 容器 共享 |P 地 址 和 端口 号 ， 它 们 之 间 可 以 通过 localhost 互相 发 现 。 它 
们 之 间 可 以 通过 进程 间 通 信 ， yn 号 或 者 POSIX 共 享 内 存 。 不 同 Pod 之 
间 的 容器 具有 不 同 的 IP 地 址 ， 不 能 直接 通过 |PC 通 信 


Pod 中 的 容器 也 有 访问 共享 volume 的 权限 ， 这 些 volume 会 被 定义 成 pod 的 一 部 分 并 
挂 载 到 应 用 容器 的 文件 系统 中 。 


根据 Docker 的 结构 ，Pod 中 的 容器 共享 namespace 和 volume， 不 支持 共享 PID 的 
namespace ° 


就 像 每 个 应 用 容器 ，pod 被 认为 是 临时 ( 非 持 久 的 ) 实体 。 在 Pod 的 生命 周期 中 讨 
论 过 ，pod 被 创建 后 ， 被 分 配 一 个 唯一 的 ID (UID) ， 调 度 到 节点 上 ， 并 一 致 维持 其 
望 的 状态 直到 被 终结 (根据 重启 策略 ) 或 者 被 删除 。 如 果 node 死 掉 了 ， 分 配 到 了 这 
个 node 上 的 pod， 在 经 过 一 个 超时 时 间 后 会 被 重新 调度 到 其 他 node 节 点 上 。 一 个 给 
定 的 pod (如 UID 定 义 的 ) 不 会 被 “重新 调度 "到 新 的 节点 上 ， 而 是 被 一 个 同样 的 pod 
取代 ， 如 果 期 望 的 话 甚 至 可 以 是 相同 的 名 字 ， 但 是 会 有 一 个 新 的 UID (查看 
replication controller 获 取 详 情 ) 。 (未 来 ， 一 个 更 高 级 别 的 AP| 将 支持 pod 迁 移 ) 。 


Pod 解 析 


Volume 跟 pod 有 相同 的 生命 周期 ( 当 其 UID 存 在 的 时 候 ) 。 当 Pod 因 为 某 种 原因 被 
删除 或 者 被 新 创建 的 相同 的 Pod 取 代 ， 它 相关 的 东西 (例如 volume) 也 会 被 销毁 和 
再 创建 一 个 新 的 volume 。 


Content 
Manager 


File Web 
Puller Server 





图 片 - Pod 示 意图 


A multi-container pod that contains a file puller and a web server that uses a 
persistent volume for shared storage between the containers. 


Pod 的 动机 

管理 

Pod 是 一 个 服务 的 多 个 进程 的 聚合 单位 ，pod 提 供 这 种 模型 能 够 简化 应 用 部 署 管 
理 ， 通 过 提供 一 个 更 高 级 别 的 抽象 的 方式 。Pod 作 为 一 个 独立 的 部 署 单位 ， 支 持 横 
向 扩展 和 复制 。 共 生 (协同 调度 ) ， 命 运 共同 体 (例如 被 终结 ) ， 协 同 复制 ， 资 源 


共享 ， 依 赖 管理 ，Pod 都 会 自动 的 为 容器 处 理 这 些 问题 。 


资源 共享 和 通信 
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Pod 中 的 应 用 可 以 共享 网 络 空间 (IP 地 址 和 端口 ) ， 因 此 可 以 通过 localhost Z 
相 发 现 。 因 此 ，pod 中 的 应 用 必须 协调 端口 占用 。 每 个 pod 都 有 一 个 唯一 的 IP 地 址 ， 
跟 物 理 机 和 其 他 pod 都 处 于 一 个 扁平 的 网 络 空间 中 ， 它 们 之 间 可 以 直接 连通 


Pod 中 应 用 容器 的 hostname 被 设置 成 Pod 的 名 字 。 


Pod 中 的 应 用 容器 可 以 共享 volume。Volume 能 够 保证 pod 重 启 时 使 用 的 数据 不 丢 
失 o 


Pod ay 4£ M] 


Pod 也 可 以 用 于 垂直 应 用 栈 (例如 LAMP) ， 这 样 使 用 的 主要 动机 是 为 了 支持 共同 
调度 和 协调 管理 应 用 程序 ， 例 如 : 


e content management systems, file and data loaders, local cache managers, 
etc. 

e log and checkpoint backup, compression, rotation, snapshotting, etc. 

e data change watchers, log tailers, logging and monitoring adapters, event 
publishers, etc. 

e proxies, bridges, and adapters 

e controllers, managers, configurators, and updaters 


常 单个 pod 中 不 会 同时 运行 一 个 应 用 的 多 个 实例 。 


详细 说 明 请 看 : The Distributed System ToolKit: Patterns for Composite 
Containers. 


其 他 替代 选择 
为 什么 不 直接 在 一 个 容器 中 运行 多 个 应 用 程序 呢 ? 


1. 透明 。 让 Pod 中 的 容器 对 基础 设施 可 见 ， 以 便 基 础 设施 能 够 为 这 些 容 器 提供 服 
务 ， 例 如 进程 管理 和 资源 监控 。 这 可 以 为 用 户 带 来 极 大 的 便利 。 

2. 解 耦 软件 依赖 。 每 个 容器 都 可 以 进行 版 本 管理 ， 独 立 的 编译 和 发 布 。 未 来 
kubernetes 甚 至 可 能 支持 单个 容器 的 在 线 升 级 。 

3. 使 用 方便 。 用 户 不 必 运 行 自己 的 进程 管理 器 ， 还 要 担心 错误 信号 传播 等 。 

4. 效率 。 因 为 由 基础 架构 提供 更 多 的 职责 ， 所 以 容器 可 以 变 得 更 加 轻 量 级 。 


为 什么 不 支持 容器 的 亲 和 性 的 协同 调度 


这 种 方法 可 以 提供 容器 的 协同 定位 ， 能 够 根据 容器 的 亲 和 性 进行 调度 ， 但 是 无 法 实 
ACE pOH NAHE 分 好 处 ， 例 如 资源 共享 ，IPC， 保 持 状态 一 致 性 和 简化 管理 


o 


A 8B 


Pod 的 持久 性 (或 者 说 缺乏 持久 性 ) 


Pod 在 设计 支持 就 不 是 作为 持久 化 实体 的 。 在 调度 失败 、 节 点 故障 、 缺 少 资源 或 者 
节点 维护 的 状态 下 都 会 死 掉 会 被 驱逐 


通常 ， 用 户 不 需要 手动 直接 创建 Pod， 而 是 应 该 使 用 controller (例如 
Deployments) ， 即 使 是 在 创建 单个 Pod 的 情况 下 。Controller 可 以 提供 集群 级 别 的 
自 念 功能 、 复 制 和 升级 管理 。 


The use of collective APIs as the primary user-facing primitive is relatively 
common among cluster scheduling systems, including Borg, Marathon, Aurora, 
and Tupperware. 


Pod is exposed as a primitive in order to facilitate: 


e scheduler and controller pluggability 

e support for pod-level operations without the need to "proxy" them via 
controller APIs 

e decoupling of pod lifetime from controller lifetime, such as for bootstrapping 

e decoupling of controllers and services — the endpoint controller just watches 
pods 

e clean composition of Kubelet-level functionality with cluster-level functionality 
— Kubelet is effectively the "pod controller" 

e high-availability applications, which will expect pods to be replaced in 
advance of their termination and certainly in advance of deletion, such as in 
the case of planned evictions, image prefetching, or live pod migration #3949 


StatefulSet controller (目前 还 是 beta 状 态 ) 支持 有 状态 的 Pod。 在 1.4 版 本 中 被 称 为 
PetSet 。 在 kubernetes 之 前 的 版 本 中 创建 有 状态 pod 的 最 佳 方式 是 创建 一 个 replica 
为 1 的 replication controller ° 


Pod 的 终止 


因为 Pod 作 为 在 集群 的 节点 上 运行 的 进程 ， 所 以 在 不 再 需要 的 时 候 能 够 优雅 的 终止 
掉 是 十 分 必要 的 ( 比 起 使 用 发 送 KILL 信 号 这 种 暴力 的 方式 ) 。 用 户 需 要 能 够 放松 删 
除 请 求 ， 并 且 知 道 它们 何 时 会 被 终止 ， 是 否 被 正确 的 删除 。 用 户 想 终止 程序 时 发 送 
删除 pod 的 请 求 ， 在 pod 可 以 被 强制 删除 前 会 有 一 个 优雅 删除 的 时 间 ， 会 发 送 一 个 
TERM 请 求 到 每 个 容器 的 主 进程 。 一 旦 超时 ， 将 向 主 进程 发 送 KILL 信 号 并 从 API 
server 中 删除 。 如 果 kubelet 或 者 container manager 在 等 待 进程 终止 的 过 程 中 重启 ， 
在 重启 后 仍然 会 重 试 完整 的 优雅 删除 阶段 。 


示例 流程 如 下 : 


. 用 户 发 送 删除 pod 的 命令 ， 默 认 优 雅 删除 时 期 是 30 秒 ; 
. 在 Pod 超 过 该 优雅 删 除 期 限 后 API server 就 会 更 新 Pod 的 状态 为 “dead”; 
. 在 客户 端 命令 行 上 显示 的 Pod 状 态 为 “terminating”; 
. 跟 第 三 步 同 时 ， 当 kubelet 发 现 pod 被 标记 为 “terminating” 状 态 时 ， 开 始 停止 pod 
进程 : 
i 如果 在 pod 中 定义 了 preStop hook， 在 停止 pod 前 会 被 调用 。 如 果 在 优雅 删 
除 期 限 过 期 后 ，preStop hook 依 然 在 运行 ， 第 二 步 会 再 增加 2 秒 的 优雅 时 
Ñ] ; 
ii 向 Pod 中 的 进程 发 送 TERM 信 号 ; 
5. 跟 第 三 步 司 时 ， 该 Pod 将 从 该 service 的 端点 列表 中 删除 ， 不 再 是 replication 
controller 的 一 部 分 。 关 闭 的 慢 的 pod 将 继续 处 理 load balancer 转 发 的 流量 ; 
6. 过 了 优雅 周期 后 ， 将 向 Pod 中 依然 运行 的 进程 发 送 SIGKILL 信 号 而 杀 掉 进程 。 
7. Kublete 会 在 API server 中 完成 Pod 的 的 删除 ， 通 过 将 优雅 周期 设置 为 0 (立即 删 
R) 。Pod 在 API 中 消失 ， 并 且 在 客户 端 也 不 可 见 。 


BOND 一 


删除 优雅 周期 默认 是 30 秒 。 kubectl delete 命令 支持 -grace-period= 
«seconds» 选项 ， 人 允许 用 户 设置 自己 的 优雅 周期 时 间 。 如 果 设 置 为 0 将 强制 删除 
pod。 在 kubectl>=1.5 版 本 的 命令 中 ， 你 必须 同时 使 用 --force 和 --grace- 
period=0 来 强制 删除 pod。 


强制 删除 Pod 


Pod 的 强制 删除 是 通过 在 集群 和 etcd 中 将 其 定义 为 删除 状态 。 当 执行 强制 删除 命令 

I} > API server 不 会 等 待 该 pod 所 运行 在 节点 上 的 kubelet 确 认 ， 就 会 立即 将 该 pod 从 
API server 中 移 除 ， 这 时 就 可 以 创建 跟 原 pod 同 名 的 pod 了 。 这 时 ， 在 节点 上 的 pod 

会 被 立即 设置 为 terminating 状 态 ， 不 过 在 被 强制 删除 之 前 依然 有 一 小 段 优雅 删除 周 

期 。 


55 a] MI T Apod A AH ACME > d iE AR A 1% A StatefulSet pod 的 情况 
下 ， 请 参考 删除 StatefulSet 中 的 pod 文 章 。 


Pod 中 容器 的 特权 模式 


从 kubernetes1.1 版 本 开始 ，pod 中 的 容器 就 可 以 开启 pneu ， 在 容器 定义 
文件 的 SecurityContext 下 使 用 privileged flag。 这 在 使 用 Linux 的 网 络 操 
uis 问 设 备 的 能 力 时 是 很 用 的 。 同 时 开局 的 特权 模式 的 Pod 中 的 容器 也 可 以 访问 

容器 外 的 进程 和 应 用 。 在 不 需要 修改 和 重新 编译 kubelet 的 情况 下 就 可 以 使 用 pod 
pee 点 的 网 络 和 存储 插件 。 


如 果 master 节 点 运行 的 是 kuberentes1.1 或 更 高 版 本 ， 而 node 节 点 的 版 本 低 于 1.1 版 
A> WAPI server 将 也 可 以 接受 新 的 特权 模式 的 pod， 但 是 无 法 启动 ，pod 将 处 于 
pending 状 态 。 


执行 kubectl describe pod FooPodName ， 可 以 看 到 为 什么 pod 处 于 pending 状 
态 。 输 出 的 event 列 表 中 将 显示 : Error validating pod 
"FooPodName"."FooPodNamespace" from api, ignoring: 
spec.containers[0].securityContext.privileged: forbidden '<*> 
(0xc2089d3248)true' 


如 果 master 节 点 的 版 本 低 于 1.1， 无 法 创建 特权 模式 的 pod。 如 果 你 仍然 试图 去 创建 
的 话 ， 你 得 到 如 下 错误 : 


The Pod "FooPodName" is invalid. 
spec.containers[0].securityContext.privileged: forbidden '<*> 
(0xc20b222db0)true' 


API Object 


Pod X Kkubernetes REST API 中 的 顶级 资源 类 型 。 


在 kuberentes1.6 的 V1 core API 版 本 中 的 Pod 的 数据 结构 如 下 图 所 示 : 


Pod 解 析 
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kubernetes 


apiVersion: v1 
kind: Pod 

name: string 
namespace: string 
selflink: string 
resourceVersion: string 


uid: string 


(.... name: string }— labels. 











annotations 





osi sing 
message: ating 
pines stina 
ped: sting 
aces: n | 





reason string 
startTime: Time | 

lastProbeTime: Time \ | 
lastTransitionTime: Time | 


message: string 





reason: strin 
status: string 
type: string 
containerlD: string 
image: string 
imagelD: string 
lastState: [running | terminated] waiting 
ready: boolean 
restartCount: integer 
state: [running | terminated] waiting 
ccontaineriD: string 
image: string 
imagelD: string "| 
lastState: [running | terminated | waiting 
ready: boolean /| 
restartCount: integer. 
state: [running | terminated] waiting 
Always | Never | OnFallure. 


restartPolic 
effect: string 
key: string 





operator: sting 





tolerationSeconds: integer 
value: string 
fsGroup: inte 





er 
runAsNonRoot: boolean | 


runAsUser: integ 
securttyContext. 





s 
supplementalGroups: [integ 


terminationGracePeriodSeconds: integer 


levet: string 


role: string 





awsElasticBlockStore 
azureDisk 
azureFile | 


cephis Y 


cinder 
configMap \ 
downwardAPI 
emptybir V 
te AW 
flexVolume 
tiocker | 
geePersistentDisk 
ghtRepo 
glusterfs .. volumes. 
hostPath 
iscsi 
name: string /| 
nts 


persistentVolumeCiaim /| 


photonPersistentDisk 
porworkVolume /| 
projected 

quobyte 

"bd 


scalelo 


Secret 
vspherevolume 
nodeName: string 
subdomain: string 
nodeSelactor: object 
serviceAccount: string 
SchedulerName: string /| 





serviceAccountName: string 








name: string 
image: string 
command: [string 
args: string 
workingDir: string 
imagePullPolicy: [Always | Never | IfNotPreseni] 
stdin: false 

stdinOnce: false 
terminationMessagePath: string 
terminationMessagePolicy : string 


tty: false 
command: [string 


name: string 
value: string. 


Reference https://kubernetes.io/docs/: 


i-referencelv1.6, 





restatPole 


High Level View 


aversion: vi 







hn: Poo 




















spec 





path: string 
port: 1-65535 


scheme: string 


postStart 


port: 1-65536 





fecycle 











prefix: string 
name: string 
configMapRef 
envFrom optional: boolean 
name: strin 
secretRef 
optional: boolean 
name: string 


containerPort: string 
hostiP: string 
hostPort: string 


protocol: string 


name: string 
‘mountPath: string 
readOnly false 
subPath: string 


memor 
resources 
cpu: string 
requests. 
memory: strin 


cpu: string 


string 






































spec 


.. containers 











securityContext |. _ priviledge: false 


name: strin 
















configMapKeyRef 


resourceFieldRef 


valueFrom 








secretKeyRef 





optional: boolean 
apiVersion: strin 
fieldPath: strin 


fieldRef 





command: [string 








path: string 








scheme: string 


livenessProbe 






tepSocket 










sucessThreshold: 0 
periodSeconds: 0 
timeoutSeconds: 0 
initialDelaySeconds: 0. 
fallureThreshold: 0 











port: number. 





host: string 







scheme: string 
name: string 






value: string 














initContainers 


affinity 
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nodeAffinity 


podAffinity 








podAntiAtfinity 











topSocket 


sucessThreshold: 0 
periodSeconds: 0 
timeoutSeconds: 0 


initialDelaySeconds: 0 





readinessProbe 




















weight: integer 1-100. 








yeferredDuringSchedulingle JuringExecution 








prefernece 


nodeSelectorTerms 








weight: integer 1-100. 


matchLabels: object 











[Always | Never  OrFalure | 

















一 | securtycoment 





Pod modaatmiy | = 








amy KH rome | = 




















podAnwatnty | = 









scheduleNmer string 


















| item | Single item 
(tems) Multiple items 


— — —* With the same structure 





















matchLabels: object. 






matchLabels: object 

















values: [string] 
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Init 4: 4 


该 特性 在 1.6 版 本 已 经 推出 beta MA » Init 容器 可 以 在 PodSpec 中 同 应 用 程序 的 
containers 数组 一 起 来 指定 。 beta 注解 的 值 将 仍 需 保留 ， 并 和 履 盖 PodSpec F 
段 值 。 


本 文 讲解 Init 容器 的 基本 概念 ， 它 是 一 种 专用 的 容器 ， 在 应 用 程序 容器 启动 之 前 运 
行 ， 并 包括 一 些 应 用 镜像 中 不 存在 的 实用 工具 和 安装 脚本 。 


Init 容器 与 普通 的 容器 非常 像 ， 除 了 如 下 两 点 : 


总 是 运行 到 成 功 完 成 为 止 。 
e 每 个 Init 容器 都 必须 在 下 一 个 Init 容器 启动 之 前 成 功 完 成 。 


如 果 Pod 的 Init 容器 失败 ，Kubernetes 会 不 断 地 重启 该 Pod， 直 到 Init 容器 成 功 
为 止 。 然 而 ， 如 果 Pod 对 应 的 restartPolicy 为 Never， 它 不 会 重新 启动 。 


指定 容器 为 Init 容器 ， 在 PodSpec 中 添加 initContainers 字段 ， 以 
v1.Container 类 型 "P" JSON 数组 的 形式 ， 还 有 app 的 containers 数组 。 
Init 容器 的 状态 在 status.initContainerStatuses 字段 中 以 容器 状态 数组 的 格 
NAE (类 似 status.containerStatuses FH) ° 


与 普通 容器 的 不 同 之 处 


Init 容器 支持 应 用 容器 的 全 部 字段 和 特性 ， 包 括 资 源 限制 、 数 据 卷 和 安全 设置 。 然 
mm? Init 容器 对 资源 请 求 和 限制 的 处 理 稍 有 不 同 ， 在 下 面 资源 处 有 说 明 。 而 且 Init 
容器 不 支持 Readiness Probe， 因 为 它们 必须 在 Pod 就 绪 之 前 运行 完成 。 


如 果 为 一 个 Pod 指定 了 多 个 Init 容器 ， 那 些 容 器 会 按 顺序 一 次 运行 一 个 。 每 个 Init 
容器 必须 运行 成 功 ， 下 一 个 才能 够 运行 。 当 所 有 的 Init 容器 运行 完成 时 ， 
Kubernetes 初始 化 Pod 并 像 平常 一 样 运行 应 用 容器 


o 


Init & 2 SETA 


AA Init 容器 具有 与 应 用 程序 容器 分 离 的 单独 镜像 ， 所 以 它们 的 启动 相关 代码 具有 
如 下 优势 : 


e 它们 可 以 包含 并 运行 实用 工具 ， 但 是 出 于 安全 考虑 不 建议 在 应 用 程序 容器 
镜像 中 包含 这 些 实用 工具 的 。 

e. 它们 可 以 包含 使 用 工具 和 定制 化 代码 来 安装 ， 但 是 不 能 出 现在 应 用 程序 镜像 
中 。 例 如 ， 创 建 镜 像 没 必 要 FROM 另 一 个 镜像 ， 只 需要 在 安装 过 程 中 使 用 类 
th sed ^ awk ^ python 或 dig 这 样 的 工具 

e 应 用 程序 镜像 可 以 分 离 出 创建 和 部 署 的 角色 ， 而 没有 必要 联合 它们 构建 一 个 单 
独 的 镜像 。 

e Init 容器 使 用 Linux Namespace， 所 以 相对 应 用 程序 容器 来 说 具有 不 同 的 文件 
系统 视图 。 因 此 ， 它 们 能 够 具有 访问 Secret 的 权限 ， 而 应 用 程序 容器 则 不 
能 。 

e 它们 必须 在 应 用 程序 容器 启动 之 前 运行 完成 ， 而 应 用 程序 容器 是 并 行 运 行 的 ， 
所 以 Init 容器 能 够 提供 了 一 种 简单 的 阻塞 或 延迟 应 用 容器 的 启动 的 方法 ， 直 到 
满足 了 一 组 先决 条 件 。 


示例 


Tox 如 何 使 用 Init 容器 的 想法 : 


e 等 待 一 个 Service 创建 完成 ， 通 过 类 似 如 下 shell 命令 


for i in {1..100}; do sleep 1; if dig myservice; then exit 
0; fi; exit 1 


e 将 Pod 注册 到 远程 服务 器 ， 通 过 在 命令 中 调用 API， 类 似 如 下 : 


curl -X POST http://$MANAGEMENT SERVICE HOST:$MANAGEMENT S 
ERVICE PORT/register -d 'instance-$(«POD NAME»)&ip-$(«POD IP» 
' 
LEN H 
e 在 启动 应 用 容器 之 前 等 一 段 时 间 ， 使 用 类 似 sleep 60 的 命令 。 


e. 克隆 Git 仓库 到 数据 卷 。 


e 将 配置 值 放 到 配置 文件 中 ， 运 行 模 板 工 具 为 主 应 用 容器 动态 地 生成 配置 文件 。 
例如 ， 在 配置 文件 中 存放 POD IP 值 ， 并 使 用 Jinja 生成 主 应 用 配置 文件 。 


更 多 详细 用 法 示例 ， 可 以 在 StatefulSet 文档 和 生产 环境 Pod 指南 中 找到 。 


使 用 Init 容器 


下 面 是 Kubernetes 1.5 版 本 yaml 文件 ， 展 示 了 一 个 具有 2 个 Init 容器 的 简单 
Pod» 第 一 个 等 待 myservice 启动 ， 第 二 个 等 待 mydb x» 一旦 这 两 个 
Service 都 启动 完成 ，Pod 将 开始 启动 。 


apiVersion: vi 
kind: Pod 
metadata: 
name: myapp-pod 
labels: 
app: myapp 
annotations: 
pod.beta.kubernetes.io/init-containers: '[ 


"name": "init-myservice", 
"image": "busybox", 
"command": ["sh", "-c", "until nslookup myservice; d 
o echo waiting for myservice; sleep 2; done;"] 
3 
{ 
"name": "init-mydb", 
"image": "busybox", 
"command": ["sh", "-c", "until nslookup mydb; do ech 
o waiting for mydb; sleep 2; done;"] 


j 
] 1 


spec: 
containers: 
- Name: myapp-container 
image: busybox 
command: ['sh', '-c', 'echo The app is running! && sleep 360 
0'] 


这 是 Kubernetes 1.6 版 本 的 新 语法 ， 尽 管 老 的 annotation 语法 仍然 可 以 使 用 。 我 
们 已 经 把 Init 容器 的 声明 移 到 spec Y: 


apiVersion: v1 
kind: Pod 
metadata: 
name: myapp-pod 
labels: 
app: myapp 
spec: 
containers: 
- name: myapp-container 
image: busybox 
command: ['sh', '-c', 'echo The app is running! && sleep 360 
0'] 
initContainers: 
- name: init-myservice 
image: busybox 
command: ['sh', '-c', 'until nslookup myservice; do echo wai 
ting for myservice; sleep 2; done;'] 
- name: init-mydb 
image: busybox 
command: ['sh', '-c', 'until nslookup mydb; do echo waiting 
for mydb; sleep 2; done;'] 


1.5 版 本 的 语法 在 1.6 版 本 仍然 可 以 使 用 ， 但 是 我 们 推荐 使 用 1.6 版 本 的 新 语法 。 
在 Kubernetes 1.6 MAF > Init 容器 在 API 中 新 建 了 一 个 字段 。 虽然 期 望 使 用 
beta 版 本 的 annotation， 但 在 未 来 发 行 版 将 会 被 废弃 掉 。 


下 面 的 yaml 文件 展示 了 mydb 和 myservice 两 个 Service : 


kind: Service 
apiVersion: v1 


metadata: 
name: myservice 
spec: 
ports: 
- protocol: TCP 
port: 80 


targetPort: 9376 
kind: Service 
apiVersion: v1 
metadata: 

name: mydb 
spec: 
ports: 
- protocol: TCP 
port: 80 
targetPort: 9377 


这 个 Pod 可 以 使 用 下 面 的 命令 进行 启动 和 调试 : 


$ kubectl create -f myapp.yaml 
pod "myapp-pod" created 
$ kubectl get -f myapp.yaml 


NAME READY STATUS RESTARTS AGE 
myapp-pod 0/1 Init:0/2 0 6m 
$ kubectl describe -f myapp.yaml 

Name: myapp - pod 

Namespace: default 

[...] 

Labels: app=myapp 

Status: Pending 


[...] 
Init Containers: 
init-myservice: 


[...] 


State: Running 
[...] 
init-mydb: 
[...] 
State: Waiting 
Reason: PodInitializing 
Ready: False 
[...] 
Containers: 


myapp-container: 


[...] 


State: Waiting 
Reason: PodInitializing 
Ready: False 
[...] 
Events: 
FirstSeen LastSeen Count From Su 
bObjectPath Type Reason 
Message 
16s 16s 1 {default-scheduler } 
Normal Scheduled 
Successfully assigned myapp-pod to 172.17.4.201 
16s 16s 1 {kubelet 172.17.4.201} sp 
ec.initContainers{init -myservice} Normal Pulling 
pulling image "busybox" 
13s 13s 1 {kubelet 172.17.4.201} sp 
ec.initContainers{init -myservice} Normal Pulled 
Successfully pulled image "busybox" 
13s 13s 1 {kubelet 172.17.4.201} sp 
ec.initContainers{init -myservice} Normal Created 


Created container with docker id 5ced34a04634; Security: [secco 
mp=unconf ined | 


13s 13s 1 {kubelet 172.17.4.201} sp 
ec.initContainers{init -myservice} Normal Started 
Started container with docker id 5ced34a04634 
$ kubectl logs myapp-pod -c init-myservice # Inspect the first i 
nit container 
$ kubectl logs myapp-pod -c init-mydb # Inspect the second 
init container 


一 旦 我 们 启动 了 mydb 和 myservice 这 两 个 Service， 我 们 能 够 看 到 Init 容器 
完成 ， 并 且 myapp-pod 被 创建 : 


$ kubectl create -f services.yaml 

service "myservice" created 

service "mydb" created 

$ kubectl get -f myapp.yaml 

NAME READY STATUS RESTARTS AGE 
myapp-pod 1/1 Running 0 9m 


这 个 例子 非常 简单 ， 但 是 应 该 能 够 为 我 们 创建 自己 的 Init 容器 提供 一 些 启 发 。 


具体 行为 


在 Pod 尼 动 过 程 中 ，Init 容器 会 按 顺序 在 网 络 和 数据 卷 初始 化 之 后 启动 。 每 个 容器 
必须 在 下 一 个 容器 启动 之 前 成 功 退 出 ^O eee eee ， 导致 容器 启动 
失败 ， 它 会 根据 Pod 的 restartPolicy 指定 的 策略 进行 重 试 。 然而 ， 如 果 Pod 
的 restartPolicy 设置 为 Always * Init 容器 失败 时 会 使 用 RestartPolicy 策 
wk o 


9 
S 


在 所 有 的 Init SERA RAZA * Pod 将 不 会 变 成 Ready RA Init 容器 的 端口 
aw Service 中 进行 聚集 。 正 在 初始 化 中 的 Pod 处 于 Pending 状态 ， 但 应 
会 将 条 件 Initializing 设置 为 true。 


如 果 Pod 重启 ， 所 有 Init 容器 必须 重新 执行 。 


xt Init 容器 spec 的 修改 ， 被 限制 在 容器 image 字段 中 。 更改 Init 容器 的 image 字 
段 ， 等 价 二 重启 kz % Pod ° 


on Init 容器 可 能 会 被 重启 、 重 试 或 者 重新 执行 ， 所 以 Init È E hg AX LIA EAR F 
。 特别 n ， 被 写 到 EmptyDirs 中 文件 的 代码 ， 应 该 对 输出 文件 可 能 已 经 存在 
= o 


Int 容器 具有 应 用 容器 的 所 有 字段 。 除 了 readinessProbe * AA Init 容器 无 法 
定义 不 同 于 完成 (completion) 的 就 绪 (readiness) 的 之 外 的 其 他 状态 。 这 会 在 
验证 过 程 中 强制 执行 。 


在 Pod 上 使 用 activeDeadlineSeconds ， 在 容器 上 使 用 livenessProbe ， 这 
样 能 够 避免 Init 容器 一 直 失 败 。 这 就 为 Init 容器 活跃 设置 了 一 个 期 限 。 


在 Pod 中 的 每 个 app e Init 容器 的 名 称 必 须 唯 一 ; 与 任何 其 它 容 器 共享 同一 个 名 
称 ， 会 在 验证 时 抛 出 错误 。 


为 Init 容器 指定 顺序 和 执行 逻辑 ， 下 面 对 资 源 使 用 的 规则 将 被 应 用 : 


e 在 所 有 Init 容器 上 定义 的 ， 任 何 特殊 资源 请 求 或 限制 的 最 大 值 ， 是 有效 初始 请 
求 /限制 
e Pod 对 资源 的 有 效 请 求 /限制 要 高 于 : 


o 所 有 应 用 容器 对 某 个 资源 的 请 求 /限制 之 和 
ee c 

e 基于 有 效 请 求 /限制 完成 调度 ， 这 意味 着 Init 容器 能 够 为 初始 化 预 留 资 源 ， 这 些 
资源 在 Pod 生命 周期 过 程 中 并 没有 被 使 用 。 


e Pod 的 有效 QoS 层 ， 是 Init 容器 和 应 用 容器 相同 的 QoS 层 。 


基于 有 效 Pod 请 求 和 限制 来 应 用 配额 和 限制 。 Pod 级 别 的 cgroups 是 基于 有 效 
Pod 请 求 和 限制 ， 和 调度 器 相同 。 


Pod 重启 的 原 


Pod 能 够 重启 ， 会 导致 Init 容器 重新 执行 ， 主 要 有 如 下 几 个 原因 : 


e 用 户 更 新 PodSpec +X Init 容器 镜像 发 生 改 变 。 应 用 容器 镜像 的 变更 只 会 重 
启 应 用 容器 。 

e Pod 基础 设施 容器 被 重启 。 这 不 多 见 ， 但 某 些 具有 root 权限 可 访问 Node 的 人 
可 能 会 这 样 做 。 

e 当 restartPolicy 设置 为 Always，Pod 中 所 有 容器 会 终止 ， 强 制 重启 ， 由 
于 垃圾 收集 导致 Init 容器 完整 的 记录 丢失 。 


支持 与 兼容 性 


Apiserver 版 本 为 1.6 或 更 高 版 本 的 集群 ， 通 过 使 用 spec.initContainers 字段 
来 支持 Init 容器 。 之 前 的 版 本 可 以 使 用 alpha 和 beta 注解 支持 Init 容器 

spec.initContainers 字段 也 被 加 入 到 alpha 和 beta 注解 中 ， rie 以 Kubernetes 
1.3.0 版 本 或 更 高 版 本 可 以 执行 Init 容器， 并 且 1.6 版 本 的 apiserver 能 够 安全 地 回 
退 到 1.5.X 版 本 ， 而 不 会 使 存在 的 已 创建 Pod 失去 Init 容器 的 功能 。 


原文 地 址 : https://k8smeetup.github.io/docs/concepts/workloads/pods/init- 


containers/ 
译 者 : shirdrn 


Copyright © jimmysong.io 2017-2018 all right reserved > powered by 
GitbookUpdated at 2018-05-09 14:15:47 


a 


ge 
Pause 3 zs 
Pause 容 器 ， 又 叫 Infra 容 器 ， 本 文 将 探究 该 容器 的 作用 与 原理 。 
我 们 知道 在 kubelet 的 配置 中 有 这 样 一 个 参数 : 


KUBELET POD INFRA CONTAINER---pod-infra-container-image-registry 
.access.redhat.com/rhel7/pod-infrastructure:latest 


上 面 是 openshift 中 的 配置 参数 ，kubernetes 中 默认 的 配置 参数 是 : 


KUBELET POD INFRA CONTAINER---pod-infra-container-image-gcr.io/g 
oogle containers/pause-amd64:3.0 


Pause 容 器 ， 是 可 以 自己 来 定义 ， 官 方 使 用 
的 gcr.io/google containers/pause-amd64:3.0 容器 的 代码 见 Github， 使 用 C 
语言 编写 。 


Pause &% % & TE M 


我 们 检查 nod 节 点 的 时 候 会 发 现 每 个 node 上 都 运行 了 很 多 的 pause 容 器 ， 例 如 如 
Fe 


$ docker ps 


CONTAINER ID IMAGE 
COMMAND CREATED STATUS 
PORTS NAMES 
2c7d50fia7be docker .i0/jimmysong/heapster -grafana-amd64@s 
ha256:d663759b3de86cf62e64a43b021f133c383e8f 7bOdc2bdd78115bc95db 
371c9a "Zrunm.sn" 3 hours ago Up 3 h 
ours k8s grafana monitoring-influxd 


b-grafana-v4-5697c6b59-76zqs kube-system 5788a3c5-29c0-11e8-9e88 
-525400005732 0 

5df93dea877a docker.io/jimmysong/heapster-influxdb-amd64Q 
sha256:a217008b68cb49e8f038c4eeb6029261f02adca81d8eae8c5c01d0303 
61274b8 "Anfluxd «config ..<" 3 hours ago Up 3 h 
ours k8s influxdb monitoring-influx 
db-grafana-v4-5697c6b59-76zqs. kube-system 5788a3c5-29c0-11e8-9e8 
8-525400005732 0 


9cec6cOef 583 jimmysong/pause-amd64:3.0 
"/pause" 3 hours ago Up 3 h 
ours k8s POD monitoring-influxdb-gr 


afana-v4-5697c6b59-76zqs_kube-system_5788a3c5-29c0-11e8 -9e88-525 
400005732_0 

54d06e30a4c7 docker.io/jimmysong/kubernetes-dashboard-amd 
64Qsha256:668710d034c4209f8fa9a342db6d8be72b6cb5fif3f696cee2379b 
8512330be4 "/dashboard --inse..." 3 hours ago Up 3 h 
ours k8s. kubernetes-dashboard kuber 
netes-dashboard-65486f5fdf-lshl7 kube-system 27c414a1-29c0-11e8- 
9e88-525400005732 0 


5abef33b0d58 jimmysong/pause-amd64:3.0 
"/pause" 3 hours ago Up 3 h 
ours k8s POD kubernetes-dashboard-6 


5486f5fdf-lshl7 kube-system 27c414a1-29c0-11e8-9e88-525400005732 
0 


kubernetes 中 的 pause 容 器 主要 为 每 个 业务 容器 提供 以 下 功能 


° Eu a a 名 空间 共享 的 基础 ; 
启用 pid 命 名 空间 ， 开 启 init 进 程 。 


在 The Almighty Pause a 文章 中 做 出 了 详细 的 说 明 ，pause 容 器 的 作用 
可 以 从 这 个 例子 中 看 出 ， 首 先 见 


IPC 


Network 


PID 


Hostname 





我 们 首先 在 节点 上 运行 一 个 pause 容 器 。 
docker run -d --name pause -p 8880:80 jimmysong/pause-amd64:3.0 


az 


然后 再 运行 一 个 nginx 容 器 ，nginx 将 为 localhost:2368 创建 一 个 代理 。 


$ cat <<EOF >> nginx.conff 
error_log stderr; 
events { worker_connections 1024; } 


http { 
access_log /dev/stdout combined; 
server { 
listen 80 default_server; 
server_name example.com www.example.com; 
location / { 
proxy_pass http://127.0.0.1:2368; 
} 
} 
} 
EOF 


$ docker run -d --name nginx -v pwd /nginx.conf:/etc/nginx/ngin 
x.conf --net=container:pause --ipc=container:pause --pid=contain 
er:pause nginx 


155 


然后 再 为 ghost 创建 一 个 应 用 容器 ， 这 是 一 款 博客 软件 。 


$ docker run -d --name ghost --net=container:pause --ipc=contain 
er:pause --pid=container:pause ghost 


现在 访问 http:Wlocalhost:8880/ 就 可 以 看 到 ghost 博客 的 界面 了 。 
解析 


pause 容 器 将 内 部 的 80 端 口 映 射 到 宿主 机 的 8880 端 口 ，pause 容 器 在 宿主 机 上 设置 

好 了 网 络 namespace 后 ，nginx 容 器 加 入 到 该 网 络 namespace 中 ， 我 们 看 到 nginx 容 
器 局 动 的 时 候 指定 了 --net=container:pause ，ghost 容 器 同样 加 入 到 了 该 网 络 

namespace 中 ， 这 样 三 个 容器 就 共享 了 网 络 ， 互 相 之 问 就 可 以 使 用 localhost 直 
接 通 信 ， --ipc=contianer:pause dC OMe ease 就 是 三 个 容器 n 
同一 个 namespace 中 ，init 进 程 为 pause ， 这 时 我 们 进入 到 ghost 容器 中 查看 进 

情 Du ° 


# ps aux 


USER PID %CPU %MEM VSZ RSS TTY STAT START TIME 
COMMAND 

root 1 0.0 0.0 1024 4? Ss 13:49 0:00 
/pause 

root 5 0.0 0.1 32432 5736 ? Ss 13:51 0:00 
nginx: master p 

systemd- 9 0.0 0.0 32980 3304 ? S 13:51 0:00 
nginx: worker p 

node 10 0.3 2.0 1254200 83788 ? Ssl 13:53 6:03 
node current/in 

root 79 0.1 0.0 4336 £812 pts/0 Ss 14:09 0:00 
sh 

root 87 0.0 0.0 17500 2080 pts/0 R+ 14:10 0:00 

ps aux 


ER 


在 ghost 容 颈 中 同时 可 以 看 到 ia ud 的 进程 ， 并 且 pause 容 器 的 PID 有 是 
1。 而 在 kubernetes 中 容器 的 PID=1 的 进程 即 为 容器 本 身 的 业务 进程 。 


参考 


e The Almighty Pause Container 
e Kubernetes A Pause % & 
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` AA 
Pod X 4 R% 
PodSecurityPolicy 类 型 的 对 象 能 够 控制 ， 是 否 可 以 向 Pod 发 送 请 求 ， 该 Pod 


能 够 影响 被 应 用 到 Pod 和 容器 的 SecurityContext 。 查看 Pod 安全 策略 建议 
获取 更 多 信息 。 


什么 是 Pod 安全 策略 ? 


Pod 安全 策略 是 集群 级 别 的 资源 ， 它 能 够 控制 Pod 运行 的 行为 ， 以 及 它 具 有 访问 


什么 的 能 力 。 PodSecurityPolicy 对 象 定义 了 一 组 条 件 ， 指 示 Pod 必须 按 系 统 
所 能 接受 的 顺序 运行 o 它们 允许 管理 员 控 制 如 下 方面 


控制 面 字段 名 称 
已 授权 容器 的 运行 privileged 


为 容器 添加 默认 的 一 组 能 


defaultAddCapabilities 


requiredDropCapabilities 


容器 能 够 请 求 添加 某 些 能 力 allowedCapabilities 
控制 卷 类 型 的 使 用 volumes 

主机 网 络 的 使 用 hostNetwork 

主机 端口 的 使 用 hostPorts 

主机 PID namespace 的 使 用 hostPID 

主机 IPC namespace 的 使 用 hostIPC 

主机 路 径 的 使 用 allowedHostPaths 
容器 的 SELinux LFX seLinux 

用 户 ID runAsUser 

配置 允许 的 补充 组 supplementalGroups 
分 配 拥 有 Pod 44% 449 FSGroup fsGroup 


必须 使 用 一 个 只 读 的 root 文件 系统 


分 为 如 下 三 类 : 


readOnlyRootFilesystem 


蔡 村 布尔 值 控制 ;这 种 类 型 的 宁 艇 站 认为 有 严格 限制 的 值 。 

。 基 于 被 允许 的 值 集合 控制 : 这 种 类 型 的 字段 会 与 这 组 值 进行 对 比 ， 以 确认 值 被 
允许 。 

。 基 于 策略 控制 : 设置 项 通过 一 种 策略 提供 的 机 制 来 生成 该 值 ， 这 种 机 制 能 够 确 
保 指定 的 值 落 在 被 允许 的 这 纽 值 中 。 


RunAsUser 


e MustRunAs - 必须 配置 一 个 range 。 使 用 该 范围 内 的 第 一 个 值 作为 默认 值 。 
验证 是 否 不 在 配置 的 该 范围 内 。 

e MustRunAsNonRoot - 要 求 提交 的 Pod LAIR runAsUser 值 ， 或 在 镜像 
中 定义 了 USER 环境 变量 。 不 提供 默认 值 。 

e RunAsAny - 没有 提供 默认 值 。 允 许 指 定 任何 runAsUser 。 


SELinux 


e MustRunAs - 如 果 没 有 使 用 预 分 配 的 值 ， 必 须 配 置 se^vlinuxOptions ° RU 
使 用 seLinuxOptions 。 验 十 seLinuxOptions 。 
e RunAsAny - 没有 提供 默认 值 。 人 允许 任意 指定 的 seLinuxoptions ID?» 


SupplementalGroups 
e MustRunAs - 至 少 需要 指定 一 个 范围 。 默 认 使 用 第 一 个 范围 的 最 小 值 。 验 证 所 
有 范围 的 值 。 
e RunAsAny - 没有 提供 默认 值 。 人 允许 任意 指定 的 supplementalGroups ID ° 


FSGroup 


e MustRunAs - 至 少 需要 指定 一 个 范围 。 默 认 使 用 第 一 个 范围 的 最 小 值 。 验 证 在 
第 一 个 范围 内 的 第 一 个 ID 。 
e RunAsAny - 没有 提供 默认 值 。 人 允许 任意 指定 的 fsGroup ID» 


控制 郑 


通过 设置 PSP 卷 字 段 ， 能 够 控制 具体 卷 类 型 的 使 用 。 当 创建 一 个 卷 的 时 候 ， 与 该 
字段 相关 的 已 定义 卷 可 以 允许 设 


. azureFile 

. azureDisk 

. flocker 

. flexvolume 

. hostPath 

. emptyDir 

. gcePersistentDisk 
. awsElasticBlockStore 
. gitRepo 

. Secret 

nfs 

. iscsi 


-— —_ wd. = 
O N> OO AND A FPF wWN > 


. glusterfs 


— 
A 


. persistentVolumeClaim 
. rbd 

. cinder 

. cephFS 

. downwardAPI 


LÀ ky ek X 2X 
(C ON Oo C1 


. fc 


N 
O 


. configMap 


N 
一 


. vsphereVolume 


N 
N 


. quobyte 


N 
CD 


. photonPersistentDisk 
. projected 
. portworxVolume 


N N N 
OOA 


. scalelO 


N 
N 


. Storageos 
28. * (allow all volumes) 


对 新 的 PSP， 推 荐 允许 的 卷 的 最 小 集合 包括 : configMap ^ downwardAPI ^ 
emptyDir ` persistentVolumeClaim ` secret 和 projected ° 


主机 网 络 


e HostPorts ， 默 认为 empty ° HostPortRange 列表 通过 min (包含 ) and 
max (包含 ) 来 定义 ， 指 定 了 被 允许 的 主机 端口 。 


允许 的 主机 路 径 


e AllowedHostPaths 是 一 个 被 允许 的 主机 路 径 前 级 的 白 名 单 。 空 值 表示 所 有 的 主 
机 路 径 都 可 以 使 用 。 


许可 

包含 PodSecurityPolicy 的 许可 控制 ， 允 许 控制 集群 资源 的 创建 和 修改 ， 基 于 
这 些 资 源 在 集群 范围 内 被 许可 的 能 力 。 

许可 使 用 如 下 的 方式 为 Pod 创建 最 终 的 安全 上 下 文 : 


1. 检索 所 有 可 用 的 PSP» 
2. 生成 在 请 求 中 没有 指定 的 安全 上 下 文 设置 的 字段 值 。 
3. 基于 可 用 的 策略 ， 验 证 最 终 的 设置 。 


如 果 某 个 策略 能 够 匹配 上 ， 该 Pod 就 被 接受 。 如 果 请 求 与 PSP 不 匹配 ， 则 Pod 被 
拒绝 。 


Pod 必须 基于 PSP 验证 每 个 字段 。 


创建 Pod 安全 策略 


下 面 是 一 个 Pod 安全 策略 的 例子 ， 所 有 字段 的 设置 都 被 允许 : 


apiVersion: extensions/vibeta1 
kind: PodSecurityPolicy 
metadata: 
name: permissive 
spec: 
seLinux: 
rule: RunAsAny 
supplementalGroups: 
rule: RunAsAny 
runAsUser: 
rule: RunAsAny 
fsGroup: 
rule: RunAsAny 
hostPorts: 
- min: 8000 
max: 8080 
volumes: 


VT 


下 载 示 例文 件 可 以 创建 该 策略 ， 然 后 执行 如 下 命令 : 


$ kubectl create -f ./psp.yaml 
podsecuritypolicy "permissive" created 


获取 Pod 安全 策略 列表 
获取 已 存在 策略 列表 ， 使 用 kubectl get 


$ kubectl get psp 


NAME PRIV CAPS SELINUX RUNASUSER FSGROUP 
UPGROUP READONLYROOTFS VOLUMES 

permissive false [] RunAsAny RunAsAny RunAsAny 
unAsAny false [*] 

privileged true [] RunAsAny RunAsAny RunAsAny 
unAsAny false [5] 

restricted false [] RunAsAny MustRunAsNonRoot RunAsAny 
unAsAny false [emptyDir secret downwardAPI configMap 


persistentVolumeClaim projected] 


修改 Pod 安全 策略 


通过 交互 方式 修改 策略 ， 使 用 kubectl edit 


$ kubectl edit psp permissive 


该 命令 将 打开 一 个 黑 认 文本 编辑 器 ， 在 这 里 能 够 修改 策略 。 


、 he 
删除 Pod LERS 
一 旦 不 再 需要 一 个 策略 ， 很 容易 通过 kubectl MRE: 


$ kubectl delete psp permissive 
podsecuritypolicy "permissive" deleted 


启用 Pod 安全 策略 
为 了 能 够 在 集群 中 使 用 Pod 安全 策略 ， 必 须 确保 如 下 : 


1. 启用 API 类 型 extensions/vibetai/podsecuritypolicy 〈 仅 对 1.6 Z 9j 
的 版 本 ) 

2. 启用 许可 控制 器 PodSecurityPolicy 

3. 定义 自己 的 策略 


使 用 RBAC 


在 Kubernetes 1.5 或 更 新 版 本 ， 可 以 使 用 PodSecurityPolicy 来 控制 ， 对 基于 用 户 
角色 和 组 的 已 授权 容器 的 访问 。 访 问 不 同 的 PodSecurityPolicy 对 象 ， 可 以 基于 认 
证 来 控制 。 基 于 Deployment ^ ReplicaSet 等 创建 的 Pod， 限 制 访问 
PodSecurityPolicy *t % > Controller Manager 必须 基于 安全 API 端口 运行 ， 并 且 不 
能 够 具有 超级 用 户 权限 。 


PodSecurityPolicy 认证 使 用 所 有 可 用 的 策略 ， 包 括 创 建 Pod 的 用 户 ，Pod 上 指定 
的 服务 账户 (service acount) ° 4 Pod 基于 Deployment ` ReplicaSet 创建 时 ， 
它 是 创建 Pod 的 Controller Manager， 所 以 如 果 基 于 非 安 全 API 端口 运行 ， 允 许 所 
有 的 PodSecurityPolicy 对 象 ， 并 且 不 能 够 有 效 地 实现 细 分 权限 。 用 户 访问 给 定 的 
PSP 策略 有 效 ， 仅 当 是 直接 部 署 Pod 的 情况 。 更 多 详情 ， 查 看 PodSecurityPolicy 
RBAC 示例 ， 当 直接 部 署 Pod 时 ， 应 用 PodSecurityPolicy 控制 基于 角色 和 组 的 已 
授权 容器 的 访问 。 


原文 地 址 : https://k8smeetup.github.io/docs/concepts/policy/pod-security-policy/ 
14 : shirdrn 


Copyright © jimmysong.io 2017-2018 all right reserved > powered by 
GitbookUpdated at 2018-05-09 14:15:47 


Pod 的 生命 周期 


Pod phase 


Pod 的 status 在 信息 保存 在 PodStatus 中 定义 ， 其 中 有 一 个 phase 字段。 


Pod 的 相位 (phase) 是 Pod 在 其 生命 周期 中 的 简单 宏观 概述 。 该 阶段 并 不 是 对 容 
器 或 Pod 的 综合 汇总 ， 也 不 是 为 了 做 为 综合 状态 机 。 


Pod 相位 的 数量 和 含义 是 严格 指定 的 。 除 了 本 文档 中 列举 的 状态 外 ， 不 应 该 再 假定 
Pod 有 其 他 的 phase 值 。 


下 面 是 phase 可 能 的 值 : 


挂 起 (Pending) : Pod 已 被 Kubernetes 系统 接受 ， 但 有 一 个 或 者 多 个 容器 镜 
像 尚未 创建 。 等 待 时 间 包 括 调度 Pod 的 时 间 和 通过 网 络 下 载 镜像 的 时 间 ， 这 可 
能 需要 花 点 时 间 。 

运行 中 (Running) : 该 Pod 已 经 绑 定 到 了 一 个 节点 上 ，Pod 中 所 有 的 容器 都 
已 被 创建 。 至 少 有 一 个 容器 正在 运行 ， 或 者 正 处 于 启动 或 重启 状态 。 

成 功 (Successed) : Pod 中 的 所 有 容器 都 被 成 功 终止 ， 并 且 不 会 再 重启 。 
失败 (Failed) : Pod 中 的 所 有 容器 都 已 终止 了 ， 并 且 至 少 有 一 个 容器 是 因为 
失败 终止 。 也 就 是 说 ， 容 器 以 非 0 状 态 退 出 或 者 被 系统 终止 。 

未 知 (Unkonwn) : 因为 某 些 原因 无 法 取得 Pod 的 状态 ， 通 常 是 因为 与 Pod 
所 在 主机 通信 失败 。 


下 图 是 Pod 的 生命 周期 示意 图 ， 从 图 中 可 以 看 到 Pod 状 态 的 变化 。 
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图 片 - Pod 的 生命 周期 示意 图 〈 图 片 来 自 网 络 ) 


Pod 状态 


Pod 有 一 个 PodStatus 对 象 ， 其 中 包含 一 个 PodCondition %28 ° PodCondition 数 
组 的 每 个 元 素 都 有 一 个 type 字段 和 一 个 status 字段 。 type 字段 是 字符 

串 ， 可 能 的 值 有 PodScheduled ` Ready ` Initialized 和 Unschedulable ° 
字段 是 一 个 字符 串 ， 可 能 的 值 有 True ` False 和 Unknown e 


status 


容器 探 针 


探 针 是 由 kubelet 对 容器 执行 的 定期 诊断 。 要 执行 诊断 ，kubelet 调用 由 容器 实现 
的 Handler。 有 三 种 类 型 的 处 理 程 序 : 


e ExecAction : 在 容器 内 执行 指定 命令 。 如 果 命 令 退 出 时 返回 码 为 0 则 认为 诊断 
成 功 。 

e TCPSocketAction : 对 指定 端口 上 的 容器 的 IP 地 址 进行 TCP 检查 。 如 果 端 口 
打开 ， 则 诊断 被 认为 是 成 功 的 。 

e HTTPGetAction : 对 指定 的 端口 和 路 径 上 的 容器 的 IP 地 址 执行 HTTP Get 请 
求 。 如 果 响 应 的 状态 码 大 于 等 于 200 且 小 于 400， 则 诊断 被 认为 是 成 功 的 。 

每 次 探测 都 将 获得 以 下 三 种 结果 之 一 : 

e 成 功 : 容器 通过 了 诊断 。 

e KK: 容器 未 通过 诊断 。 

e 未 知 : seen ， 因 此 不 会 采取 任何 行动 。 


Kubelet 可 以 选择 是 否 执行 在 容器 上 运行 的 两 种 探 针 执行 和 做 出 反应 : 


e livenessProbe : 指示 容器 是 否 正 在 运行 。 如 果 存 活 探测 失败 ， 则 kubelet 
会 杀 死 容器 ， 并 且 容 器 将 受到 其 重启 策略 的 影响 。 如 果 容 器 不 提供 存活 探 
针 ， 则 默认 状态 为 Success ° 

e readinessProbe : 指示 容器 是 否 准备 好 服务 请 求 。 如 果 就 绪 探 测 失 败 ， 端 
点 控制 器 将 从 与 Pod 匹配 的 所 有 Service 的 端点 中 删除 该 Pod 的 IP 地 址 。 初 
始 延 迟 之 前 的 就 绪 状 态 默 认为 “Failure 。 如 果 容 器 不 提供 就 绪 探 针 ， 则 默认 
状态 为 Success ° 


该 什么 时 候 使 用 存活 (liveness) 和 就 绪 
(readiness) 探 针 ? 


如 果 容器 中 的 进程 能 够 在 遇 到 问题 或 不 健康 的 情况 下 自行 崩溃 ， 则 不 一 定 需要 存活 
探 针 ; kubelet 将 根据 Pod 的 restartPolicy 自动 执行 正确 的 操作 。 


如 果 您 希望 容器 在 探测 失败 时 被 杀 死 并 重新 启动 ， 那 么 请 指定 一 个 存活 探 针 ， 并 指 
Æ restartPolicy 为 Always X OnFailure ° 


如 果 要 仅 在 探测 成 功 时 才 开 始 向 Pod 发 送 流量 ， 请 指定 就 绪 探 针 。 在 这 种 情况 下 ， 
就 绪 探 针 可 能 与 存活 探 针 相同 ， 但 是 spec 中 的 就 绪 探 针 的 存在 意味 着 Pod FEA 
有 接收 到 任何 流量 的 情况 下 启动 ， 并 且 只 有 在 探 针 探测 成 功 后 才 开 始 接收 流量 。 


如 果 您 希望 容器 能 够 自行 维护 ， 您 可 以 指定 一 个 就 绪 探 针 ， 该 探 针 检查 与 存活 探 针 
不 同 的 端点 。 


请 注意 ， 如 果 您 只 想 在 Pod 被 删除 时 能 够 排除 请 求 ， 则 不 一 定 需要 使 用 p ; 
在 删除 Pod Ht > Pod 会 自动 将 自 于 未 完成 状态 ， 无 论 就 绪 探 针 是 否 存在 。 当 
ff Pod 中 的 容器 停止 时 ，Pod 仍 处 于 未 完成 状态 。 


Pod 和 容器 状态 


AR Pod 容器 状态 的 详细 信息 ， 请 参阅 PodStatus 和 ContainerStatus。 请 注意 ， 
报告 的 Pod 状态 信息 取决 于 当前 的 ContainerState ° 


PodSpec 中 有 一 个 restartPolicy 字段 ， 可 能 的 值 为 Always ` OnFailure 和 
Never ° RUX Always ° restartPolicy 适用 于 Pod 中 的 所 有 容 

器 。 restartPolicy 仅 指 通过 同一 节点 上 的 kubelet 重新 启动 容器 。 失 败 的 容器 
由 kubelet 以 五 分 钟 为 上 限 的 指数 退 避 延迟 (10 秒 ，20 稍 ，40 秒 ...) 重新 启动 ， 并 
在 成 功 执行 十 分 钟 后 重 置 。 如 Pod 文档 中 所 述 ， 一 旦 绑 定 到 一 个 节点 ，Pod HA 
远 不 会 重新 绑 定 到 另 一 个 节点 。 


Pod 的 生命 


一 般 来 说 ，Pod 不 会 消失 ， 直 到 人 为 销毁 他 们 。 这 可 能 是 一 个 人 或 控制 器 。 这 个 规 
则 的 唯一 例外 是 成 功 或 失败 的 _ phase 超过 一 段 时 间 (由 master 确定 ) 的 Pod 将 
期 并 被 自动 销毁 。 


过 
有 三 种 可 用 的 控制 器 : 


e 使 用 Job 运行 预期 会 终止 的 Pod， 例 如 批量 计算 。Job 仅 适 用 于 重启 策略 为 
OnFailure 或 Never 的 Pod。 


e 对 预期 不 会 终止 的 Pod 使 用 ReplicationController、ReplicaSet 和 
Deployment ， 例 如 Web 服务 器 。 ReplicationController 仅 适 用 于 具有 
restartPolicy 为 Always 的 Pod ° 
e 提供 特定 于 机 器 的 系统 服务 ， 使 用 DaemonSet 为 每 台 机 器 运行 一 个 Pod 。 


所 有 这 三 种 类 型 的 控制 器 都 包含 一 人 Podtemplate 。 建 议 创建 适当 的 控制 器 ， 让 它 
们 来 创建 Pod， 而 不 是 直接 自己 创建 Pod。 这 是 因为 单独 的 Pod 在 机 器 故障 的 情 
况 下 没有 办 法 自动 复原 ， 而 控制 器 却 可 以 。 


如 果 节 点 死亡 或 与 集群 的 其 余部 分 断 开 连接 ， 则 Kubernetes 将 应 用 一 个 策略 将 丢 
失 节 点 上 的 所 有 Pod 的 phase 设置 为 Failed。 


示例 


高 级 liveness 探 针 示例 


存活 探 针 由 kubelet 来 执行 ， 因 此 所 有 的 请 求 都 在 kubelet 的 网 络 命名 空间 中 进 
行 9 


apiVersion: v1 
kind: Pod 
metadata: 
labels: 
test: liveness 
name: liveness-http 
spec: 
containers: 
- args: 
- /server 
image: gcr.io/google containers/liveness 
livenessProbe: 


httpGet: 
# when "host" is not defined, "PodIP" will be used 


# host: my-host 
# when "scheme" is not defined, "HTTP" scheme will be us 
ed. Only "HTTP" and "HTTPS" are allowed 

# scheme: HTTPS 

path: /healthz 

port: 8080 

httpHeaders: 

- name: X-Custom-Header 
value: Awesome 
initialDelaySeconds: 15 
timeoutSeconds: 1 
name: liveness 


状态 AS 7h “all 


e Pod 中 只 有 一 个 容器 并 且 正 在 运行 。 容 器 成 功 退出 。 
o 记录 完成 事件 。 
o 如 果 Ce PE AE A: 
a Always: 重启 容器 ; Pod phase 4157) Running ° 
= OnFailure : Pod phase Z X Succeeded ° 
m Never: Pod phase ee Succeeded ° 
e Pod 中 只 有 一 个 容器 并 且 正 在 运行 。 容 器 退出 失败 。 
o 记录 失败 事件 。 
o 如 果 CA A: 
a Always: 重启 容器 ; Pod phase 4157; Running ° 
= OnFailure : 重启 容器 ; Pod phase 4157; Running ° 
m Never : Pod phase 变 成 Failed ° 
e Pod 中 有 两 个 容器 并 且 正 在 运行 。 有 一 个 容器 退出 失败 。 


o 记录 失败 事件 。 
o 如 果 restartPolicy 为 : 


= Always: 重启 容器 ; Pod phase 仍 为 Running。 
= OnFailure : 重启 容器 ; Pod phase 仍 为 Running。 
=» Never: 不 重启 容器 ; Pod phase 2A Running o 


o 如 果 有 一 个 容器 没有 处 于 运行 状态 ， 并 且 两 个 容器 退出 : 


m 记录 失败 事件 。 
m 如果 restartPolicy 为 : 
= Always: 重启 容器 ; Pod phase 仍 为 Running。 
= OnFailure : 重启 容器 ; Pod phase 仍 为 Running。 
=» Never: Pod phase "XX Failed ° 
e Pod 中 只 有 一 个 容器 并 处 于 运行 状态 。 容 器 运行 时 内 存 超出 限制 : 
o 容器 以 失败 状态 终止 。 
o HA OOM 事件 。 
o 如 果 restartPolicy A: 
a Always: 重启 容器 ; Pod phase 1% Running ° 
a OnFailure : 重启 容器 ; Pod phase 1% Running ° 
m Never: 记录 失败 事件 ; Pod phase 15A Failed ° 
e Pod EZI o BAKE : 
o 杀 掉 所 有 容器 。 
o GRKE 当 事 件 。 
o Pod p 变 成 Failed 。 
o 如 果 使 用 控制 器 来 运行 ，Pod 将 在 别处 重建 。 
e Pod 正在 运行 ， 其 节点 被 分 段 。 
o PALER 器 等 待 直 到 超时 。 
o indt 器 将 Pod phase 设置 为 Failed ° 
o 如 果 是 用 控制 器 来 运行 ，Pod 将 在 别处 重建 


原文 地 址 : https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/ 
翻译 : rootsongjc 


Copyright © jimmysong.io 2017-2018 all right reserved > powered by 
GitbookUpdated at 2018-05-09 14:15:47 


Pod 的 生命 周期 


171 


Pod hook 


Pod hook (44-7) ada dnd kubelet 发 起 的 ， 当 容器 中 的 进程 启动 前 
或 者 容器 中 的 进程 终止 之 前 运行 ， 这 是 包含 在 容器 的 生命 周期 之 中 。 可 以 同时 为 


Pod 中 的 所 有 容器 都 配置 hook。 
Hook 的 类 型 包括 两 种 : 


e exec : 执行 一 段 命 令 
。 HTTP : 发 送 HTTP 请 求 。 


参考 下 面 的 配置 


apiVersion: vi 
kind: Pod 
metadata: 
name: lifecycle-demo 
spec: 
containers: 
- name: lifecycle-demo-container 
image: nginx 
lifecycle: 
poststart: 


exec: 
command: ["/bin/sh", "-c", "echo Hello from the postSt 


art handler > /usr/share/message" | 
preStop: 
exec: 
command: ["/usr/sbin/nginx","-s", "quit" ] 


n» 器 创建 之 后 ， 容 器 的 Entrypoint 执 行 之 前 ， 这 时 候 Pod 已 经 被 调度 到 某 台 node 

' 被 茶 个 kubelet 管 理 了 ， 这 时 候 kubelet 会 调用 postStart 操 作 ， 该 操作 跟 容器 的 
局 pue 是 在 异步 执行 的 ， 也 就 是 说 在 postStart 操 作 执行 完成 之 前 ，kubelet 会 锁 住 
容器 ， 不 让 应 用 程序 的 进程 启动 ， 只 有 在 postStart 操 作 完 成 之 后 容器 的 状态 才 会 被 
设置 成 为 RUNNING。 


如 果 postStart 或 者 preStop hook 失 败 ， 将 会 终止 容器 。 


调试 hook 


Hook 调 用 的 日 志 没 有 暴露 个 给 Pod 的 event， 所 以 只 能 通过 describe 命令 来 获 
取 ， 如 果 有 错误 将 可 以 看 到 FailedPostStartHook 或 FailedPreStopHook 这 样 
的 event 。 


e Attach Handlers to Container Lifecycle Events 


e Container Lifecycle Hooks 
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Pod Preset 


注意 : PodPreset 资源 对 和 象 只 有 kubernetes 1.8 以 上 版 本 才 支 持 。 


Preset 就 是 预 设 ， 有 时 候 想 要 让 一 批 容 器 在 启动 的 时 候 就 注入 一 些 信 jl ， 比 如 
secret ` volume ` volume mount 和 环境 变量 ， 而 又 不 想 一 个 一 个 的 改 这 些 Pod 的 
tmeplate ， 这 时 候 就 可 以 用 到 PodPreset 这 个 资源 对 象 了 。 


本 页 是 关于 PodPreset 的 概述 ， 该 对 象 用 来 在 Pod 创建 的 时 候 向 Pod 中 注入 某 些 
特定 信息 。 该 信息 可 以 包括 secret、volume、volume mount 和 环境 变量 。 


理解 Pod Preset 


Pod Preset 是 用 来 在 Pod 被 创建 的 时 候 向 其 中 注入 额外 的 运行 时 需求 的 API 资 
源 。 


您 可 以 使 用 label selector 来 指定 为 哪些 Pod 应 用 Pod Preset。 


使 用 Pod Preset 使 得 pod 模板 的 作者 可 以 不 必 为 每 个 Pod 明确 提供 所 有 信息 。 这 
样 一 来 ，pod 模板 的 作者 就 不 需要 知道 关于 该 服务 的 所 有 细节 。 


关于 该 背景 的 更 多 信息 ， 请 参阅 PodPreset 的 设计 方案 。 


如 何 工 作 


Kubernetes 提供 了 一 个 准 入 控制 器 ( PodPreset ) ， 当 其 启用 时 ，Pod Preset 
会 将 应 用 创建 请 求 传 入 到 该 控制 器 上 。 当 有 Pod 创建 请 求 发 生 时 ， 系 统 将 执行 以 下 
操作 : 


1. 检索 所 有 可 用 的 PodPresets 。 

2. 检查 PodPreset 标签 选择 器 上 的 标签 ， 看 看 其 是 否 能 够 匹配 正在 创建 的 Pod 
上 的 标签 。 

3. 尝试 将 由 PodPreset 定义 的 各 种 资源 合并 到 正在 创建 的 Pod 中 。 

4. 出 现 错误 时 ， 在 该 Pod 上 引发 记录 合并 错误 的 事件 ，PodPreset 不 会 注入 任何 
资源 到 创建 的 Pod 中 。 

5. 注释 刚 生 成 的 修改 过 的 Pod spec， 以 表明 它 已 被 PodPreset 修改 过 。 注 释 的 


格式 为 podpreset.admission.kubernetes.io/podpreset-«pod-preset 


name>": "<resource version>" ° 


& Pod 可 以 匹配 零 个 或 多 个 Pod Prestet: 并 且 每 个 PodPreset TXUE T X 
个 或 多 个 Pode PodPreset 应 用 于 一 个 或 多 个 Pod 时 ，Kubernetes 会 修改 Pod 
Spec。 对 于 Env ^ EnvFrom 和 VolumeMounts 的 更 改 ，Kubernetes 修改 
Pod 中 所 有 容器 的 容器 spec: 对 于 volume 的 更 改 ，Kubernetes 修改 Pod 


注意 : Pod Preset 可 以 在 适当 的 时 候 修 改 Pod spec 中 的 spec.containers 
字段 。Pod Preset 中 的 资源 定义 将 不 会 应 用 于 initContainers 字段 。 


禁用 特定 Pod 的 Pod Preset 


在 某 些 情况 下 ， 您 可 能 不 希望 Pod 被 任何 Pod Preset 所 改变 。 在 这 些 情况 下 ， 您 
可 以 在 Pod 的 Pod Spec 中 添加 注 


释 : podpreset.admission.kubernetes.io/exclude: "true" ° 


尼 用 Pod Preset 


为 了 在 群集 中 使 用 Pod Preset， 您 必须 确保 以 下 内 容 : 


1. 您 已 启用 settings.k8s.io/vialphai/podpreset API 类 型 。 例 如 ， 可 以 
通过 在 API server 的 --runtime-config 选项 中 包含 
settings.k8s.io/vialphai-true 来 完成 此 操作 。 

2. 您 已 启用 PodPreset 准 入 控制 器 。 一 种 方法 是 将 PodPreset 包含 在 为 
API server 指定 的 --admission-control 选项 值 中 。 

3. 您 已 经 在 要 使 用 的 命名 空间 中 通过 创建 PodPreset 对 象 来 定义 


PodPreset ° 


e 使 用 PodPreset 向 Pod 中 注入 数据 


本 文 为 Kubernetes 官方 中 文 文档 ， 地 
At : https://kubernetes.io/cn/docs/concepts/workloads/pods/podpreset/ 


翻译 : rootsongjc 
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Pod 中 断 与 PDB (Pod ¥ Eri # ) 


这 篇 文档 适用 于 要 构建 高 可 用 应 用 程序 的 所 有 者 ， 因 此 他 们 需要 了 解 Pod 可 能 发 生 
什么 类 型 的 中 断 。 也 适用 于 要 执行 自动 集群 操作 的 集群 管理 员 ， 如 升级 和 集群 自动 
"nee 


o 


Y 


自愿 中 断 和 非 自愿 中 断 


Pod 不 会 消失 ， 直 到 有 人 (人 类 或 控制 器 ) 将 其 销毁 ， 或 者 当 出 现 不 可 避免 的 硬件 
或 系统 软件 错误 。 


我 们 把 这 些 不 可 避免 的 情况 称 为 应 用 的 非 自愿 性 中 断 。 例 妈 


e 后 端 节点 物理 机 的 硬件 故障 

e 集群 管理 员 错 误 地 删除 虚拟 机 (实例 ) 
e 云 提 供 商 或 管理 程序 故障 使 虚拟 机 消失 
e AZA (kernel panic) 

e 节点 由 于 集群 网 络 分 区 而 从 集群 中 消失 
e 由 于 节点 资源 不 足 而 将 容器 逐 出 


除 资源 不 足 的 情况 外 ， 大 多 数 用 户 应 该 都 熟悉 以 下 这 些 情况 ; 它们 不 是 特定 于 
Kubernetes 的 。 


我 们 称 这 些 情况 为 "自愿 中 断 “。 和 包括 由 应 用 程序 所 有 者 发 起 的 操作 和 由 集群 管理 员 
发 起 的 操作 。 典 型 的 应 用 程序 所 有 者 操作 包括 : 


e 删除 管理 该 pod 的 Deployment 或 其 他 控制 器 
e 更 新 了 Deployment 的 pod 模板 导致 pod € È 
e 直接 删除 pod. (意外 删除 ) 


集群 管理 员 操 作 和 包括 : 


e HES (drain) 节点 进行 修复 或 升级 。 
e 从 集群 中 排 空 节点 以 缩小 集群 (了 解 集群 自动 调节 ) e 
e 从 节点 中 移 除 一 个 pod， 以 允许 其 他 pod 使 用 该 节点 。 


这 些 操作 可 能 由 集群 管理 员 直 接 执行 ， 也 可 能 由 集群 管理 员 或 集群 托管 提供 商 自动 


询问 您 的 集群 管理 员 或 咨询 您 的 云 提供 商 或 发 行文 档 ， 以 确定 是 否 为 您 的 集群 启用 
了 任何 自动 中 断 源 。 如 果 没 有 启用 ， 您 可 以 跳 过 创建 Pod Disruption Budget (Pod 
中 断 预 算 ) 。 


处 理 中 断 


以 下 是 一 些 减 轻 非 自愿 性 中 断 的 方法 : 


e 确保 您 的 pod 请 求 所 需 的 资源 。 

。 如 果 您 需要 更 高 的 可 用 性 ， 请 复制 您 的 应 用 程序 。 (了 解 有 关 运 行 复制 的 无 状 
态 和 有 状态 应 用 程序 的 信息 。) 

。 为 了 在 运行 复制 应 用 程序 时 获得 更 高 的 可 用 性 ， 请 跨 机 架 (使 用 反 亲 和 性 ) X 
跨 区 域 (如 果 使 用 多 区 域 集群 ) 分 布 应 用 程序 。 


自愿 中 断 的 频率 各 不 相同 。 在 Kubernetes 集群 上 上， 根本 没有 自愿 的 中 断 。 但 是 ， 
您 的 集群 管理 员 或 托管 提供 商 可 能 会 运行 一 些 导 致 自愿 中 断 的 附加 服务 。 例 如 ， 节 
点 软件 更 新 可 能 导致 自愿 更 新 。 另 外 ， 集 群 (节点) 自动 缩放 的 某 些 实现 可 能 会 导 
致 碎片 整理 和 紧缩 节点 的 自愿 中 断 。 您 的 集群 管理 员 或 主机 提供 商 应 该 已 经 记录 了 
期 望 的 自愿 中 断 级 别 〈 如 果 有 的 话 ) © 


Kubernetes 提供 的 功能 可 以 满足 在 频繁 地 自动 中 断 的 同时 运行 高 可 用 的 应 用 程序 。 
我 们 称 之 为 “中 断 预 算 ”。 


中 断 预 算 的 工作 原理 


应 用 程序 所 有 者 可 以 为 每 个 应 用 程序 创建 一 个 PodDisruptionBudget 对 象 
(PDB) » PDB 将 限制 在 同一 时 间 自 愿 中 断 的 复制 应 用 程序 中 宕 机 的 Pod 的 数 
量 。 例 如 ， 基 于 定额 的 应 用 程序 希望 确保 运行 的 副本 数量 永远 不 会 低 于 仲裁 所 需 的 
数量 。Web 前 端 可 能 希望 确保 提供 负载 的 副本 的 数量 永远 不 会 低 于 总 数 的 茶 个 百 分 
比 。 


集群 管理 器 和 托管 提供 商 应 使 用 遵循 Pod Disruption Budgets 的 工具 ， 方 法 是 
WM Eviction API 而 不 是 直接 删除 Pod。 例 如 kubectl drain 命令 和 
Kubernetes-on-GCE 集群 升级 脚本 〈 cluster/gce/upgrade.sh ) œ 


当 集 群 管理 员 想 要 排 空 节点 时 ， 可 以 使 用 kubectl drain 命令 。 该 命令 会 试图 
驱逐 机 器 上 的 所 有 pod。 了 驱逐 请 求 可 能 会 暂时 被 拒绝 ， 并 且 该 工具 会 定期 重 试 所 有 
失败 的 请 求 ， 直 到 所 有 的 pod 都 被 终止 ， 或 者 直到 达到 配置 的 超时 时 间 。 


PDB 指定 应 用 程序 可 以 容忍 的 副本 的 数量 ， 相 对 于 应 该 有 多 少 副 本 。 例 如 ， 具 有 

spec.replicas :5 的 Deployment 在 任何 给 定 的 时 间 都 应 该 有 5 个 Pod。 如 果 
其 PDB 允许 在 茶 一 时 刻 有 4 个 副本 ， 那 么 驱逐 API 将 只 允许 仅 有 一 个 而 不 是 两 个 
Pod 自愿 中 断 。 


使 用 标签 选择 器 来 指定 应 用 程序 的 一 组 pod， 这 与 应 用 程序 的 控制 器 
(Deployment ` StatefulSet 等 ) 使 用 的 相同 。 


Pod 控制 器 的 .spec.replicas 计算 “预期 的 "pod 数量 。 使 用 对 象 的 


ak 


.metadata.ownerReferences 值 从 控制 器 获取 。 
PDB 不 能 阻止 非 自愿 中 断 的 发 生 ， 但 是 它们 确实 会 影响 预算 。 


由 于 应 用 程序 的 滚动 升级 而 被 删除 或 不 可 用 的 Pod 确实 会 计 入 中 断 预 算 ， 但 控制 器 
(如 Deployment 和 StatefulSet) 在 进行 滚动 升级 时 不 受 PDB 的 限制 一 一 在 应 用 
程序 更 新 期 间 的 故障 处 理 是 在 控制 器 的 规格 (spec) 中 配置 (了解 更 新 
Deployment) 。 

使 用 驱逐 API 驱逐 pod 时 ，pod 会 被 优雅 地 终止 (请 参阅 PodSpec 中 的 


terminationGracePeriodSeconds ) ° 


PDB 示例 


假设 集群 有 3 个 节点 ， node-1 到 node-3 。 集 群 中 运行 了 一 些 应 用 ， 其 中 一 个 
应 用 有 3 个 副本 ， 分 别 是 pod-a ^ pod-b 和 pod-c 。 另 外 ， 还 有 一 个 与 它 相 
关 的 不 具有 PDB 的 pod， 我 们 称 为 之 为 pod-x 。 最 初 ， 所 有 Pod 的 分 布 如 下 : 


node-1 node-2 node-3 
pod-a available pod-b available pod-c available 
pod-x available 
所 有 的 3 个 pod 48 Deployment 中 的 一 部 分 ， 并 且 它 们 共同 拥有 一 个 PDB， 要 求 
至 少 有 3 个 pod 中 的 2 个 始终 处 于 可 用 状态 。 
例如 ， 假 设 集群 管理 员 想 要 重启 系统 ， 升 级 内 核 版 本 来 修复 内 核 中 的 错误 。 集 群 管 
理 员 首先 使 用 kubectl drain 命令 尝试 排除 node-1 。 该 工具 试图 驱逐 pod- 


a 和 pod-x 。 这 立即 成 功 。 两 个 Pod 同时 进入 终止 状态 。 这 时 的 集群 处 于 这 种 
AA: 


node-1 draining node-2 node-3 
pod-a terminating pod-b available pod-c available 
pod-x terminating 
Deployment 注意 到 其 中 有 一 个 pod 处 于 正在 终止 ， 因 此 会 创建 了 一 个 pod-d X 
替换 。 由 于 node-1 被 封锁 (cordon) ， 它 落 在 另 一 个 节点 上 。 同 时 其 它 控 制 器 
也 创建 了 pod-y 作为 pod-x 的 替代 品 。 
(注意 :对 于 statefulset > pod-a 将 被 称 为 pod-1 ， 需 要 在 替换 之 前 完全 
终止 ， 替 代 它 的 也 称 为 ”pod-1 ， 但 是 具有 不 同 的 UID， 可 以 创建 。 否 则 ， 示 例 也 
适用 于 StatefulSet » ) 


当前 集群 的 状态 如 下 : 


node-1 draining node-2 node-3 
pod-a terminating pod-b available pod-c available 
pod-x terminating pod-d starting pod-y 


在 某 一 时 刻 ，pod 被 终止 ， 集 群 看 起 来 像 下 面 这 样子 : 


node-1 drained node-2 node-3 
pod-b available pod-c available 
pod-d starting pod-y 


此 时 ， 如 果 一 个 急躁 的 集群 管理 员 试 图 排 空 (drain) node-2 3 node-3 ， 
drain 命令 将 被 阻塞 ， 因 为 对 于 Deployment 只 有 2 个 可 用 的 pod， 并 且 其 PDB 至 
少 需要 2 个 。 经 过 一 段 时 间 ， pod-d 变 得 可 用 。 


node-1 drained node-2 node-3 
pod-b available pod-c available 
pod-d available pod-y 


现在 ， 集 群 管 理 员 尝 试 排 空 node-2 ° drain 命令 将 尝试 按照 某 种 顺序 驱逐 两 个 
pod， 假 设 先是 pod-b ， 然 后 再 pod-d 。 它 将 成 功 驱 过 pod-b 。 但 是 ， 当 它 
试图 驱逐 pod-d 时 ， 将 被 拒绝 ， 因 为 这 样 对 Deployment 来 说 将 只 剩 下 一 个 可 用 
的 pod ° 


Deployment 将 创建 一 个 名 为 pod-e 的 pod-b 的 替代 品 。 人 但是， 集群 中 没有 足 
够 的 资源 来 安排 pod-e 。 那 么 ，drain 命令 就 会 被 阻塞 。 集 群 最 终 可 能 是 这 种 状 
Ac 


mos 


node-1 drained node-2 node-3 no node 
pod-b available pod-c available pod-e pending 
pod-d available pod-y 


此 时 ， 集 群 管理 员 需 要 向 集群 中 添加 回 一 个 节点 以 继续 升级 操作 。 
您 可 以 看 到 Kubernetes 如 何 改 变 中 断 发 生 的 速率 ， 根 据 : 


e 应 用 程序 需要 多 少 副本 

e 正常 关闭 实例 需要 多 长 时 间 
e 局 动 新 实例 需要 多 长 时 间 
e 控制 器 的 类 型 

o 集群 的 资源 能 


分 离 集群 所 有 者 和 应 用 程序 所 有 者 角色 


将 集群 管理 者 和 应 用 程序 所 有 者 视 为 彼此 知识 有 限 的 独立 角色 通常 是 很 有 用 的 。 这 
种 责任 分 离 在 这 些 情况 下 可 能 是 有 意义 的 : 


e 当 有 许多 应 用 程序 团队 共享 一 个 Kubernetes 集群 ， 并 且 有 自然 的 专业 角色 
e 使 用 第 三 方 工具 或 服务 来 自动 化 集群 管理 


Pod Disruption Budget (Pod 中 断 预算 ) 通过 在 角色 之 间 提 供 接 口 来 支持 这 种 角色 
分 离 。 


如 果 您 的 组 织 中 没有 这 样 的 职责 分 离 ， 则 可 能 不 需要 使 用 Pod 中 断 预算 。 


如 何在 集群 上 执行 中 断 操 作 
如 果 您 是 集群 管理 员 ， 要 对 集群 的 所 有 节点 执行 中 断 操作 ， 例 如 节点 或 系统 软件 升 
级 ， 则 可 以 使 用 以 下 选择 : 


e. 在 升级 期 间接 受 停机 时 间 。 
e. 故障 转移 到 另 一 个 完整 的 副本 集群 。 


o 没有 停机 时 间 ， 但 是 对 于 重复 的 节点 和 人 工 协调 成 本 可 能 是 昂贵 的 。 
e 编写 可 容忍 中 断 的 应 用 程序 和 使 用 PDB © 
o 没有 停机 时 间 。 
o 最 小 的 资源 重复 。 
o 允许 更 多 的 集群 管理 自动 化 。 
o 编写 可 容忍 中 断 的 应 用 程序 是 很 业 手 的 ， 但 对 于 可 容忍 自愿 中 断 ， 和 支持 
自动 调整 以 容忍 非 自 愿 中 断 ， 两 者 在 工作 上 有 大 量 的 重合。 


e Disruptions - kubernetes.io 
e 通过 配置 Pod Disruption Budget (Pod 中 断 预算 ) 来 执行 保护 应 用 程序 的 步 
e 了 解 更 多 关于 排 空 节点 的 信息 。 
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集群 信息 


为 了 管理 异 构 和 不 同 配置 的 主机 ， 为 了 便于 Pod 的 运 维 管理 ， Selous 
很 多 集群 管理 的 配 pa 能 ， 通 过 namespace 划 分 的 空间 ， 通 过 为 node 节 点 创 
建 label 和 taint 用 于 pod 的 调度 等 
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Node 


Node 是 kubernetes 集 群 的 工作 节点 ， 可 以 是 物理 机 也 可 以 是 虚拟 机 。 


Node 的 状态 
Node 和 包括 如 下 状态 信息 : 


e Address 
o HostName : 可 以 被 kubelet 中 的 --hostname-override 参数 替代 。 
o ExternallP : 可 以 被 集群 外 部 路 由 到 的 |P 地 址 。 
o InternallP : 集群 内 部 使 用 的 IP， 集 群 外 部 无 法 访问 。 
e Condition 
o OutOfDisk : 磁盘 空间 不 足 时 为 True 
o Ready : Node controller 40 秒 内 没有 收 到 node 的 状态 报告 为 Unknown ， 
健康 为 True > GMA False 。 
o MemoryPressure : 妆 node 没 有 内 存 压力 时 为 True > GIA False 。 
o DiskPressure : 当 node 没 有 磁盘 压力 时 为 True > SRA False 。 
e Capacity 
o CPU 
o AF 
o 可 运行 的 最 大 Pod 个 数 
e Info: 节点 的 一 些 版 本 信息 ， 如 OS、kubernetes、docker 等 


大 大 
Node ¢ #2 
禁止 pod 调 度 到 该 节点 上 
kubectl cordon <node> 
驱逐 该 节点 上 的 所 有 pod 


kubectl drain <node> 


该 命令 会 删除 该 节点 上 的 所 有 Pod (DaemonSet 除 外 ) ， 在 其 他 node 上 重新 启动 它 
们 ， 通 常 该 节点 需要 维护 时 使 用 该 命令 。 直 接 使 用 该 命令 会 自动 调用 kubectl 
cordon «node» 命令 。 当 该 节点 维护 完成 ， 启 动 了 kubelet 后 ， 再 使 用 kubectl 
uncordon <node> 即 可 将 该 节点 添加 到 kubernetes 集 群 中 。 
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Namespace 


在 一 个 Kubernetes 集 群 中 可 以 使 用 namespace 创 建 多 个 “虚拟 集群 ”， 这 些 
namespace 之 问 可 以 完全 隔离 ， 也 可 以 通过 某 种 方式 ， 让 一 个 namespace 中 的 
service 可 以 访问 到 其 他 的 namespace 中 的 服务 ， 我 们 在 CentOS 中 部 署 
kubernetes1.6 集 群 的 时 候 就 用 到 了 好 几 个 跨越 namespace 的 服务 ， 比 如 Traefik 
ingress 和 kube-system namespace 下 的 service 就 可 以 为 整个 集群 提供 服务 ， 这 
些 都 需要 通过 RBAC 定 义 集群 级 别 的 角色 来 实现 。 


哪些 情况 下 适合 使 用 多 个 namespace 


因为 namespace 可 以 提供 独立 的 命名 空间 ， 因 此 可 以 实现 部 分 的 环境 隔离 。 当 你 的 
项 目 和 人 员 众 多 的 时 候 可 以 考虑 根据 项 目 属性 ， 例 如 和 生产、 测试、 开发 划分 不 同 的 
namespace ° 


Namespace 使 用 
获取 集群 中 有 哪些 namespace 


kubectl get ns 


集群 中 默认 会 有 default 和 kube-system 这 两 个 namespace ° 
在 执行 kubectl 命令 时 可 以 使 用 -n 指定 操作 的 namespace。 


用 户 的 普通 应 用 默认 是 在 default 下 ， 与 集群 管理 相关 的 为 整个 集群 提供 服务 的 
应 用 一 般 部 署 在 kube-system 的 namespace 下 ， 例 如 我 们 在 安装 kubernetes 集 群 
时 部 署 的 kubedns ^ heapseter ^ EFK 等 都 是 在 这 个 namespace 下 面 。 


另外 ， 并 不 是 所 有 的 资源 对 象 都 会 对 应 
namespace， node 和 persistentVolume 就 不 属于 任何 namespace。 
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Namespace 


187 


Label 


Label 是 附着 到 object 上 (例如 Pod) 的 键 值 对 。 可 以 在 创建 object 的 时 候 指定 ， 也 
可 以 在 object 创 建 后 随时 指定 。Labels 的 值 对 系统 本 身 并 没有 什么 含义 ， 只 是 对 用 
户 才 有 意义 。 


"labels": { 
"keyi" : "valuei", 
"key2" : "value2" 
J 


Kubernetes 了 最终 将 对 labels 最 终 索 引 和 反 向 索引 用 来 优化 查询 和 watch， 在 Ul 和 命令 
行 中 会 对 它们 排序 。 不 要 在 label 中 使 用 大 型 、 非 标识 的 结构 化 数据 ， 记 录 这 样 的 数 
据 应 仿 用 annotation ° 


动机 


Label 能 够 将 组 织 架构 映射 到 系统 架构 上 (就 像 是 康 威 定律 ) ， 这 样 能 够 更 便于 微 
服务 的 管理 ， 你 可 以 给 object 打 上 如 下 类 型 的 label : 


e "release" : "stable" , "release" : "canary" 
e "environment" : "dev" , "environment" : "qa" , "environment" : 
"production" 
e "tier" : "frontend" , "tier" : "backend" , "tier" : "cache" 
e "partition" : "customerA" , "partition" : "customerB" 
e "track" : "daily" , "track" : "weekly" 
e "team" : "teamA" , "team:" : "teamB" 
语法 和 字符 集 


Label key 的 组 成 : 


e 不 得 超过 63 个 字符 
。 可 以 使 用 前 级 ， 使 用 /分 隔 ， 前 级 必须 是 DNS 子 域 ， 不 得 超过 253 个 字符 ， 系 统 
中 的 自动 化 组 件 创建 的 label 必 须 指定 前 级 ， kubernetes.io/ 由 kubernetes 


保留 
e 起 始 必须 是 字母 《大 小 写 都 可 以 ) 或 数字 ， 中 间 可 以 有 连 字符 、 下 划 线 和 点 


Label value 的 组 成 : 


。 不 得 超过 63 个 字符 
e 起 始 必须 是 字母 (大 小 写 都 可 以 ) 或 数字 ， 中 间 可 以 有 连 字 符 、 下 划 线 和 点 


Label selector 


Label 不 是 唯一 的 ， 很 多 object 可 能 有 相同 的 label。 


通过 label selector， 客 户 端 一 用 户 可 以 指定 一 个 object 集 合 ， 通 过 label selector 对 
object 的 集合 进行 操作 。 


Label selector 有 两 种 类 型 


e equality-based : 可 以 使 用 = ` == ^ != 操作 符 ， 可 以 使 用 过 号 分 隔 多 个 
表达 式 

e set-based : 可 以 使 用 in ^ notin ` ! 操作 符 ， 另 外 还 可 以 没有 操作 符 ， 
直接 写 出 茶 个 label 的 key， 表 示 过 滤 有 某 个 key 的 object 而 不 管 该 key 的 value 是 
何 值 ， ! 表示 没有 该 label 的 object 


示例 


$ kubectl get pods -1 environment=production, tier=frontend 

$ kubectl get pods -1 ‘environment in (production),tier in (fron 
tend) ' 

$ kubectl get pods -1 ‘environment in (production, qa)' 

$ kubectl get pods -1 'environment,environment notin (frontend) ' 


Æ API object ? 7% £ label selector 


在 service ^ replicationcontroller 等 object 中 有 对 pod 的 label selector > 1% 
用 方法 只 能 使 用 等 于 操作 ， 例 如 : 


selector: 
component: redis 


Label 


在 Job ^ De PO ^ ReplicaSet 和 DaemonSet 这 些 object 中 ， 支 持 set- 
based 的 过 滤 ， 例 如 


selector: 
matchLabels: 
component: redis 
matchExpressions: 
{key: tier, operator: In, values: [cache]} 
{key: environment, operator: NotIn, values: [dev]} 


如 Service 通 过 label selector 将 同一 类 型 的 pod 作 为 一 个 服务 expose 出 来 。 






Kubernetes Cluster 


Kubernetes Master 








p ' ' 
Container | Container |i! | Container | Container |i! 


时 Pod ®D Pod Qj» Pod ® Pod 
Node Node 


> = Labels VN - Service 


图 片 - /abe/ 示 意图 


另外 在 node affinity 和 pod affinity 中 的 label selector 的 语法 又 有 些许 不 同 ， 示 例如 
Fi 
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affinity: 
nodeAffinity: 
requiredDuringSchedulingIgnoredDuringExecution: 
nodeSelectorTerms: 
- matchExpressions: 
- key: kubernetes.io/e2e-az-name 
operator: In 
values: 
- e2e-azi 
- e2e-az2 
preferredDuringSchedulingIgnoredDuringExecution: 
- weight: 1 
preference: 
matchExpressions: 
- key: another -node-label-key 
Operator: In 
values: 
- another -node-label-value 


详 见 node selection ° 
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Annotation 


Annotation » LZ X: > 35:5 i£ AE » Annotation "T 43$ Kubernetes 9t 75 s HK HK 5] 
任意 的 非 标识 性 元 数据 。 使 用 客户 端 ( 如 工具 和 库 ) 可 以 检索 到 这 些 元 数据 。 


关联 元 数据 到 对 象 


Label 和 Annotation 都 可 以 将 元 数据 关联 到 Kubernetes 资 源 对 象 。Label 主 要 用 于 选 
择 对 象 ， 可 以 挑选 出 满足 特定 条 件 的 对 象 。 相 比 之 下 ，annotation 不 能 用 于 标识 及 
选择 对 象 。annotation 中 的 元 数据 可 多 可 少 ， 可 以 是 结构 化 的 或 非 结 构 化 的 ， 也 可 
以 包含 label 中 不 允许 出 现 的 字符 。 


annotation 和 |abel 一 样 都 是 key/value 键 值 对 映射 结构 : 


"annotations": { 
"keyi" : "valuei", 
"key2" : "value2" 

} 


guy 


以 下 列 出 了 一 些 可 以 记录 在 annotation 中 的 对 象 信 ，， 


e 声明 配置 层 管理 的 字段 。 使 用 annotation 关 联 这 类 字段 可 以 用 于 区 分 以 下 几 种 
配置 来 源 : 客户 端 或 服务 器 设置 的 默认 值 ， 自动 生成 的 字段 或 自动 生成 的 
auto-scaling 和 auto-sizing 系统 配置 的 字段 。 

e 创建 信息 、 版 本 信息 或 镜像 信息 。 例 如 时 间 玲 、 版 本 号 、git 分 支 、PR 序 
镜像 哈 希 值 以 及 仓库 地 址 。 

e 记录 上 日志、 监控、 分析 或 审计 存储 仓库 的 指针 


e 可 以 用 于 debug 的 客户 端 〈 库 或 工具 ) 信息 ， 例 如 名 称 、 版 本 和 创建 信息 。 

e 用 户 人 信息， 以 及 工具 或 系统 来 源 信 息 、 例 如 来 自 非 Kubernetes 生 态 的 相关 对 象 
的 URL 信 息 

e j 量 级 部 署 工具 元 数据 ， 例 如 配置 或 检查 点 。 

e 负责 人 的 电话 或 联系 方式 ， 或 能 找到 相关 信息 的 目录 条 目 信 息 ， 例 如 团队 网 


如 果 不 使 用 annotation， 您 也 可 以 将 以 上 类 型 的 信息 存放 在 外 部 数据 库 或 目录 中 ， 
但 这 样 做 不 利于 创建 用 于 部 署 、 管 理 、 内 部 检查 的 共享 工具 和 客户 端 库 。 


示例 
如 Istio 的 Deployment 配置 中 就 使 用 到 了 annotation : 


apiVersion: extensions/vibeta1 
kind: Deployment 
metadata: 
name: istio-manager 
spec: 
replicas: 1 
template: 
metadata: 
annotations: 
alpha.istio.io/sidecar: ignore 
labels: 
istio: manager 
spec: 
serviceAccountName: istio-manager-service-account 
containers: 
- name: discovery 
image: harbor-001.jimmysong.io/library/manager:0.1.5 
imagePullPolicy: Always 
args: ["discovery", *-v", "2*] 


ports: 
- containerPort: 8080 
env: 
- name: POD NAMESPACE 
valueFrom: 
fieldRef: 


apiVersion: vi 
fieldPath: metadata.namespace 
- name: apiserver 
image: harbor-001.jimmysong.io/library/manager:0.1.5 
imagePullPolicy: Always 
args: ["apiserver", "-v", "2"] 


ports: 
- containerPort: 8081 
env: 
- name: POD NAMESPACE 
valueFrom: 
fieldRef: 


apiVersion: vi 
fieldPath: metadata.namespace 


alpha.istio.io/sidecar 注解 就 是 用 来 控制 是 否 自动 向 pod 中 注入 sidecar 
的 。 参 考 : 安装 lstio sidecar - istio.doczh.cn ° 
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Taint 和 Toleration (污点 和 容忍 ) 


Taint (污点 ) 和 Toleration (容忍 ) 可 以 作用 于 node fe pod 上， 其 目的 是 优化 

pod 在 集群 间 的 调度 ， 这 跟 节 点 亲 和 性 类 似 ， 只 不 过 它们 作用 的 方式 相反 ， 具 有 
taint 的 node 和 pod 是 互 斥 关系 ， 而 具有 节点 亲 和 性 关系 的 node fe pod 是 相 吸 
的 。 另 外 还 有 可 以 给 node 节点 设置 label， 通 过 给 pod 设置 nodeSelector 将 
pod 调度 到 具有 匹配 标签 的 节点 上 。 


Taint 和 toleration 相互 配合 ， 可 以 用 来 避免 pod 被 分 配 到 不 合适 的 节点 上 。 每 个 节 

点 上 都 可 以 应 用 一 个 或 多 个 taint ， 这 表示 对 于 那些 不 能 容忍 这 些 taint 的 pod » X 

不 会 被 该 节点 接受 的 。 如 果 将 toleration 应 用 于 pod 上 ， 则 表示 这 些 pod 可 以 (但 
要 求 ) 被 调度 到 具有 相应 taint 的 节点 上 。 


示例 


以 下 分 别 以 为 node 设置 taint 和 为 pod 设置 toleration 为 例 。 


A node 设置 taint 
为 node1 设置 taint : 


kubectl taint nodes node1 keyi-valuei1:NoSchedule 
kubectl taint nodes nodei keyi-value1:NoExecute 
kubectl taint nodes nodei key2-value2:NoSchedule 


删除 上 面 的 taint : 


kubectl taint nodes nodei keyi:NoSchedule- 
kubectl taint nodes node1 keyi:NoExecute- 
kubectl taint nodes nodei key2:NoSchedule- 


查看 node1 上 的 taint : 


kubectl describe nodes nodei 


A pod 设置 toleration 
只 要 在 pod 的 spec 中 设置 tolerations 字段 即 可 ， 可 以 有 多 个 key ， 如 下 所 示 : 


tolerations: 

- key: "key1" 
operator: "Equal" 
value: "value1" 
effect: "NoSchedule" 

- key: "key1" 
operator: "Equal" 
value: "value1" 
effect: "NoExecute" 

- key: "node.alpha.kubernetes.io/unreachable" 
operator: "Exists" 
effect: "NoExecute" 
tolerationSeconds: 6000 


e value 的 值 可 以 为 NoSchedule ^ PreferNoSchedule 或 
NoExecute ° 

e tolerationSeconds 是 当 pod 需要 被 驱逐 时 ， 可 以 继续 在 node 上 运行 的 
时 间 。 


详细 使 用 方法 请 参考 官方 文档 。 


e Taints and Tolerations - kuberentes.io 
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垃圾 收集 


Kubernetes 垃圾 收集 器 的 角色 是 删除 指定 的 对 象 ， 这 些 对 象 曾 经 有 但 以 后 不 再 拥有 
Owner f ° 


注意 : 垃圾 收集 是 beta 特性 ， 在 Kubernetes 1.4 及 以 上 版 本 默认 启用 。 


Owner 和 Dependent 


一 些 Kubernetes 对 象 是 其 它 一 些 的 Owner。 例 如 ， 一 个 ReplicaSet 是 一 组 Pod 
的 Owner。 具 有 Owner 的 对 象 被 称 为 是 Owner 的 Dependent。 每 个 Dependent 
对 象 具 有 一 个 指向 其 所 属 对 象 的 metadata.ownerReferences 字段 。 


有 时 ，Kubernetes 会 自动 设置 ownerReference 的 值 。 例 如 ， 当 创建 一 个 

ReplicaSet 时 ，Kubernetes 自动 设置 ReplicaSet 中 每 个 Pod 的 
ownerReference 字段 值 。 在 1.6 版 本 ，Kubernetes 会 自动 为 一 些 对 象 设 置 
ownerReference 的 值 ， 这 些 对 象 是 由 ReplicationController ` ReplicaSet ` 

StatefulSet、DaemonSet 和 Deployment 所 创建 或 管理 。 


也 可 以 通过 手动 设置 ownerReference 的 值 ， 来 指定 Owner 和 Dependent Z Ñ 
的 关系 。 


这 有 一 个 配置 文件 ， 表 示 一 个 具有 3 个 Pod 的 ReplicaSet : 


apiVersion: extensions/vibeta1 
kind: ReplicaSet 
metadata: 
name: my-repset 
spec: 
replicas: 3 
selector: 
matchLabels: 
pod-is-for: garbage-collection-example 
template: 
metadata: 
labels: 
pod-is-for: garbage-collection-example 
spec: 
containers: 
- name: nginx 
image: nginx 


如 果 创 建 该 ReplicaSet， 然 后 查看 Pod 的 metadata 字段 ， 能 够 看 到 
OwnerReferences 字段 : 


kubectl create -f https://k8s.io/docs/concepts/abstractions/cont 
rollers/my-repset.yaml 
kubectl get pods --output=yaml 


输出 显示 了 Pod 的 Owner 是 名 为 my-repset 的 ReplicaSet : 


apiVersion: vi 
kind: Pod 
metadata: 


ownerReferences: 
- apiVersion: extensions/vibeta1 
controller: true 
blockOwnerDeletion: true 
kind: ReplicaSet 
name: my-repset 
uid: d9607e19-f88f -11e6-a518 -42010a800195 


dz d 52 I | 8H Dependent 


当 删 除 对 象 时 ， 可 以 指定 是 否 该 对 象 的 Dependent 也 自动 删除 掉 。 自 动 删除 
Dependent 也 称 为 级 联 删除 。Kubernetes 中 有 两 种 级 联 删 除 的 模 
式 : background 模式 和 foreground 模式 。 


如 果 删 除 对 象 时 ， 不 自动 删除 它 的 Dependent， 这 些 Dependent 被 称 作 是 原 对 象 
的 IJU ° 


Background 级 联 删 除 


在 background 级 联 删 除 模式 下 ，Kubernetes 会 立即 删除 Owner 对 象 ， 然 后 垃圾 
收集 器 会 在 后 台 删 除 这 些 Dependent。 


Foreground 级 联 删 除 


在 foreground GK MIKE 模式 下 ， 根 对 象 首 先进 入 “删除 中 ” 状态。 在 “删除 中 ” 状态 
会 有 如 下 的 情况 : 


e 3431A T VA REST API 可 见 
e 会 设置 对 象 的 deletionTimestamp 字段 


e 对 象 的 metadata.finalizers 字段 包含 了 值 “foregroundDeletion” 


一 旦 被 设置 为 “删除 中 ” 状态， 垃圾 收集 器 会 删除 对 象 的 所 有 Dependent。 垃 圾 收集 
器 删除 了 所 有 “Blocking ”的 Dependent (对 象 的 
ownerReference.blockOwnerDeletion=true ) 之 后 ， 它 会 删除 Owner 3t $. » 


注意 ， 在 “foreground 删除 ”模式 下 ，Dependent 只 有 通过 

ownerReference.blockOwnerDeletion 才能 阻止 删除 Owner 对 象 。 在 
Kubernetes 1.7 版 本 中 将 增加 admission controller > A Owner 对 象 上 的 删除 权 
限 来 控制 用 户 去 设置 blockOwnerDeletion 的 值 为 true， 所 以 未 授权 的 
Dependent 不 能 够 延迟 Owner 对 象 的 删除 。 


如 果 一 个 对 象 的 ownerReferences 字段 被 一 个 Controller〈 例 如 Deployment 或 
ReplicaSet) 设置 ， blockOwnerDeletion 会 被 自动 设置 ， 没 必要 手动 修改 这 个 
字段 。 


及 置 级 联 删除 策略 


通过 为 Owner 对 象 设 置 deleteOptions.propagationPolicy 字段 ， 可 以 控制 
级 联 删除 策略 。 可 能 的 取 值 包括 : “orphan”`“Foreground” 或 “Background”。 


对 很 多 Controller 资源 ， 包 括 ReplicationController ` ReplicaSet ` StatefulSet ` 
DaemonSet 和 Deployment， 默 认 的 垃圾 收集 策略 是 orphan 。 因 此 ， 除 非 指 定 
其 它 的 垃圾 收集 策略 ， 否 则 所 有 Dependent 对 象 使 用 的 都 是 orphan 策略 。 


下 面 是 一 个 在 后 台 删 除 Dependent 对 象 的 例子 


kubectl proxy --port=8080 

curl -X DELETE localhost:8080/apis/extensions/vibetai/namespaces 
/default/replicasets/my-repset \ 

-d '{"kind":"DeleteOptions", "apiVersion":"vi","propagationPolicy 
":"Background"}' \ 

-H "Content-Type: application/json" 


下 面 是 一 个 在 前 台 删 除 Dependent 对 象 的 例子 : 


kubectl proxy --port=8080 

curl -X DELETE localhost:8080/apis/extensions/vibetai/namespaces 
/default/replicasets/my-repset \ 

-d '{"kind":"DeleteOptions", "apiVersion":"vi","propagationPolicy 
":"Foreground"}' \ 

-H "Content-Type: application/json" 


下 面 是 一 个 孤儿 Dependent 的 例子 : 


kubectl proxy --port=8080 

curl -X DELETE localhost:8080/apis/extensions/vibetai/namespaces 
/default/replicasets/my-repset \ 

-d '{"kind":"DeleteOptions", "apiVersion":"vi","propagationPolicy 
"il"Orphan" ?"' N 

-H "Content-Type: application/json" 


kubectl 也 支持 级 联 删 除 。 通 过 设置 --cascade 为 true， 可 以 使 用 kubectl 自动 
删除 Dependent *1 & ° 4E --cascade A false > 21% Dependent 对 象 成 为 孤 
JL Dependent *1 € » --cascade 的 默认 值 是 true ° 


下 面 是 一 个 例子 ， 使 一 个 ReplicaSet 的 Dependent 对 象 成 为 孤儿 Dependent : 


kubectl delete replicaset my-repset --cascade=false 


已 知 的 问题 
e 1.7 版本， 垃圾 收集 不 支持 自 定 义 资 源 ， 比 如 那些 通过 
CustomResourceDefinition 新 增 ， 或 者 通过 API server 聚集 而 成 的 资源 对 象 。 
其 它 已 知 的 问题 


原文 地 
址 : https://k8smeetup.github.io/docs/concepts/workloads/controllers/garbage- 
collection/ 


译 者 : shirdrn 
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垃圾 收集 


201 


x aua, 
控制 32 
Kubernetes ? A & T 4k 2 controller (控制 器 ) ， 这 些 相 当 于 一 个 状态 机 ， 用 来 控制 
Pod 的 具体 状态 和 行为 。 
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Deployment 


Deployment 为 Pod 和 ReplicaSet 4& £t J — 4-5 A AZ 3 (declarative) 7 X > AK 
替代 以 前 的 ReplicationController 来 方便 的 管理 应 用 。 典 型 的 应 用 场景 包括 : 


e 定义 Deployment 来 创建 Pod 和 ReplicaSet 
e 滚动 升级 和 回 滚 应 用 

@ 扩容 和 缩 容 

e 暂停 和 继续 Deployment 


比如 一 个 简单 的 nginx 应 用 可 以 定义 为 


apiVersion: extensions/vibetai 
kind: Deployment 
metadata: 
name: nginx-deployment 
spec: 
replicas: 3 
template: 
metadata: 
labels: 
app: nginx 
spec: 
containers: 
- name: nginx 
image: nginx:1.7.9 
ports: 
- containerPort: 80 


扩容 : 


kubectl scale deployment nginx-deployment --replicas 10 


如 果 集 群 支持 horizontal pod autoscaling 的 话 ， 还 可 以 为 Deployment 设 置 自动 扩 
展 : 


kubectl autoscale deployment nginx-deployment --min=10 --max=15 
- -cpu-percent=80 


更 新 镜像 也 比较 简单 : 
kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1 
uU: 


kubectl rollout undo deployment/nginx-deployment 


Deployment 结构 示意 图 


参考 : https://kubernetes.io/docs/api-reference/v1.6/#deploymentspec-v1beta1- 
apps 


Deployment 





Sheet 


Reference https://kubernetes. io/docs/api-reference/v1.6/ 





Deployment Cheat 


kubernetes 


minReadySeconds: 0 


paused: boolean 
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paused: boolean 














apiVersior: apps/vibeta 
kind: Deployment 
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progressDeadlineSeconds: 600 


replicas: 1 


revisionHistoryLimit: 2 


reversion: integer rollbackTo 


key: string 
values: string array 


spec 


matchExpressions 
selector 


matchLabels: object | | 


maxSurge: 25% 
maxUnavailable: 25% 


type: [Recreate | RollingUpdate] 


rollingUpdate 
strategy 


metadata: ObjectMetadata 


Deployment 


template 
spece: PodSpec 


availableReplicas: integer 
lastTransitionTime: Time 


lastUpdateTime: Time 


message: string 


condition 


reason: string 


g 
E 
g 





string 
type: string 
observedGeneration: integer 
readyReplicas: integer 
replicas: integer 


unavailableReplicas: integer 


updatedReplicas: integer 





| apiVersion: apps/vi beta 
kind: Deployment 





| biockOvnerDeleion: ase | false 


ownerReferences 


resourceVersion: string 
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Deployment 71 4 ? 


Deployment PodfeReplica Set (下 一 代 Replication Controller) 提供 声明 式 更 
新 。 


您 只 需要 在 Deployment 中 描述 您 想 要 的 目标 状态 是 什么 ，Deployment controller 
就 会 帮 您 将 Pod 和 ReplicaSet 的 实际 状态 改变 到 您 的 目标 状态 。 您 可 以 定义 一 个 
全 新 的 Deployment 来 创建 ReplicaSet 或 者 删除 已 有 的 Deployment 并 创建 一 个 新 
的 来 替换 。 


注意 : 您 不 该 手动 管理 由 Deployment 创建 的 ReplicaSet > FM RREA T 
Deployment controller 的 职责 ! 下 文 罗列 了 Deployment 对 象 中 已 经 覆盖 了 所 有 的 
用 例 。 如 果 未 有 履 盖 您 所 有 需要 的 用 例 ， 请 直接 在 Kubernetes 的 代码 库 中 提 
issue ° 


典型 的 用 例如 下 


e 使 用 Deployment 来 创建 ReplicaSet。ReplicaSet 在 后 台 创 建 pod。 检 查 局 动 状 
态 ， 看 它 是 成 功 还 是 失败 。 

e 然后 ， 通 RA AD MET OE 明 Pod 的 新 状态 。 这 
会 创建 一 个 新 的 ReplicaSet，Deployment 会 按照 控制 的 速率 将 pod 从 昌 的 
ReplicaSet 移 动 到 新 的 ReplicaSet 中 。 

e 如 果 当 前 状态 不 稳定 ， 回 滚 到 之 前 的 Deployment revision » &:X ER Ap zx 8 3 
Deployment 的 revision ° 

e 扩容 Deployment 以 满足 更 高 的 负载 。 

e 暂停 Deployment 来 应 用 PodTemplateSpec 的 多 个 修复 ， 然 后 恢复 上 线 。 

e 根据 Deployment 的 状态 判断 上 线 是 否 hang 住 了 。 

e 清除 日 的 不 必要 的 ReplicaSet 。 


创建 Deployment 


下 面 是 一 个 Deployment 示例 ， 它 创建 了 一 个 ReplicaSet 来 启动 3 个 nginx pod 。 


下 载 示例 文件 并 执行 命令 


$ kubectl create -f https://kubernetes.io/docs/user -guide/nginx- 
deployment.yaml --record 
deployment "nginx-deployment" created 


将 kubectl 的 --record 的 flag 设置 为 true 可 以 在 annotation 中 记录 当前 命令 
创建 或 者 升级 了 该 资源 。 这 在 未 来 会 很 有 有 用， 例如， 查看 在 每 个 Deployment 
revision 中 执行 了 哪些 命令 。 


然后 立即 执行 get 将 获得 如 下 结果 : 


$ kubectl get deployments 


NAME DESIRED CURRENT UP-TO-DATE AVAILABLE 
AGE 

nginx-deployment 3 0 0 0 

1s 


输出 结果 表明 我 们 希望 的 repalica 数 是 3 (根据 deployment 中 

的 .spec.replicas 配置 ) 当前 replica 数 ( .status.replicas ) 是 0, 最 新 的 
replica 数 ( .status.updatedReplicas ) 是 0， 可 用 的 replica 数 

( .status.availableReplicas ) 是 0。 


过 几 秒 后 再 执行 get 命令 ， 将 获得 如 下 输出 : 


$ kubectl get deployments 


NAME DESIRED CURRENT UP-TO-DATE AVAILABLE 
AGE 

nginx-deployment 3 3 3 3 

18s 


我 们 可 以 看 到 Deployment 已 经 创建 了 3 个 replica > Pf 7j & replica 都 已 经 是 最 新 的 
了 (包含 最 新 的 pod template) ， 可 用 的 (根据 Deployment 中 

的 .spec.minReadySeconds 声明 ， 处 于 已 就 绪 状 态 的 pod 的 最 少 个 数 ) o dA 

^f kubectl get rs 和 kubectl get pods 会 显示 Replica Set (RS) 和 Pod 已 
创建 。 


$ kubectl get rs 
NAME DESIRED CURRENT READY AGE 
nginx-deployment-2035384211 3 3 0 18s 


您 可 能 会 注意 到 ReplicaSet 的 名 字 总 是 <Deployment 的 名 字 >-<pod template“) 
hash 值 > ° 


$ kubectl get pods --show-labels 


NAME READY STATUS RESTARTS 
AGE LABELS 
nginx-deployment-2035384211-7ci70 1/1 Running 0 
18s app=nginx, pod-template-hash=2035384211 
nginx -deployment -2035384211-kzszj 1/1 Running 0 
18s app=nginx, pod-template-hash=2035384211 
nginx-deployment-2035384211-qqcnn 1/1 Running 0 
18s app=nginx, pod-template-hash=2035384211 


刚 创建 的 Replica Set 将 保证 总 是 有 3 个 nginx 的 pod 存在 。 


注意 : 您 必须 在 Deployment 中 的 selector 指定 正确 的 pod template label (在 该 
示例 中 是 app = nginx ) ， 不 要 跟 其 他 的 controller 的 selector 中 指定 的 pod 
template label 搞 混 了 (包括 Deployment ` Replica Set ^ Replication Controller 
等 ) »Kubernetes 本 身 并 不 会 阻止 您 任意 指定 pod template label ， 但 是 如 果 您 
I 85 3x ART > 3X X5 controller 之 间 会 相互 打架 ， 并 可 能 导致 不 正确 的 行为 。 


Pod-template-hash label 
注意 : 这 个 label 不 是 用 户 指定 的 | 


注意 上 面 示例 输出 中 的 pod label 里 的 pod-template-hash label ° 2+ Deployment 
创建 或 者 接管 ReplicaSet 时 ，Deployment controller 会 自动 为 Pod 添加 pod- 
template-hash label。 这 样 做 的 目的 是 防止 Deployment 的 子 ReplicaSet 的 pod 名 
字 重 复 。 通 过 将 ReplicaSet 的 PodTemplate 进行 哈 希 散 列 ， 使 用 生成 的 哈 希 值 作 
A label 的 值 ， 并 添加 到 ReplicaSet selector €. ^ pod template label 和 
ReplicaSet 管理 中 的 Pod 上 。 


更 新 Deployment 


注意 : Deployment 的 rollout 4 4.4 4 Deployment 的 pod template ( ff] 
如 .spec.template ) 中 的 labe| 更 新 或 者 镜像 更 改 时 被 触发 。 其 他 更 新 ， 例 如 扩 
容 Deployment 不 会 触发 rollout ° 


假如 我 们 现在 想 要 让 nginx pod 使 用 nginx:1.9.1 的 镜像 来 代替 原来 
的 nginx:1.7.9 的 镜像 。 


$ kubectl set image deployment/nginx-deployment nginx=nginx:1.9. 
1 
deployment "nginx-deployment" image updated 


我 们 可 以 使 用 edit 命令 来 编辑 Deployment > 14 zx 
.spec.template.spec.containers[0].image ， 将 nginx:1.7.9 改写 成 
nginx:1.9.1 ° 


$ kubectl edit deployment/nginx-deployment 
deployment "nginx-deployment" edited 


查看 rollout 的 状态 ， 只 要 执行 


$ kubectl rollout status deployment/nginx-deployment 

Waiting for rollout to finish: 2 out of 3 new replicas have been 
updated... 

deployment "nginx-deployment" successfully rolled out 


Rollout 成 功 后 ， get Deployment : 


$ kubectl get deployments 


NAME DESIRED CURRENT UP-TO-DATE AVAILABLE 
AGE 

nginx-deployment 3 3 3 3 

36s 


UP-TO-DATE 的 replica 的 数目 已 经 达到 了 配置 中 要 求 的 数目 。 
CURRENT 的 replica 数 表示 Deployment 管理 的 replica 数量 ，AVAILABLE 的 
replica 数 是 当前 可 用 的 replica 数 量 。 


我 们 通过 执行 kubectl get rs 可 以 看 到 Deployment 更 新 了 Pod， 通 过 创建 
新 的 ReplicaSet 并 扩容 了 3 个 replica， 同 时 将 原来 的 ReplicaSet 缩 容 到 了 0 个 
replica ° 


$ kubectl get rs 


NAME DESIRED CURRENT READY AGE 
nginx-deployment-1564180365 3 3 0 6s 
nginx-deployment-2035384211 0 0 0 36s 


执行 get pods 只 会 看 到 当前 的 新 的 pod: 


$ kubectl get pods 


NAME READY STATUS RESTARTS 
AGE 
nginx -deployment -1564180365-khku8 1/1 Running 0 
14s 
nginx-deployment -1564180365-nacti 1/1 Running 0 
14s 
nginx-deployment -1564180365-z9gth 1/1 Running 0 
14s 


下 次 更 新 这 些 pod 的 时 候 ， 只 需要 更 新 Deployment 中 的 pod 的 template PPT ° 


Deployment 可 以 保证 在 升级 时 只 有 一 定数 量 的 Pod 是 down 的 。 默 认 的 ， 它 会 确 
保 至 少 有 上 比 期 望 的 Pod 数 量 少 一 个 是 up 状态 (最 多 一 个 不 可 用 ) © 


Deployment 同时 也 可 以 确保 只 创建 出 超过 期 望 数量 的 一 定数 量 的 Pod。 默 认 的 ， 
它 会 确保 最 多 比 期 望 的 Pod 数 量 多 一 个 的 Pod 是 up 的 (最 多 1 个 surge ) 。 

在 未 来 的 Kuberentes 版 本 中 ， 将 从 1-1 变 成 25%-25%。 

例如 ， 如 果 您 自己 看 下 上 面 的 Deployment， 您 会 发 现 ， 开 始 创建 一 个 新 的 Pod » 


然后 删除 一 些 昌 的 Pod 再 创建 一 个 新 的 。 当 新 的 Pod 创 建 出 来 之 前 不 会 杀 掉 旧 的 
Pod。 这 样 能 够 确保 可 用 的 Pod 数量 至 少 有 2 个 ，Pod 的 总 数 最 多 4 个 。 


$ kubectl describe deployments 


Name: nginx-deployment 
Namespace: default 
CreationTimestamp: Tue, 15 Mar 2016 12:01:06 -0700 
Labels: app=nginx 
Selector: app=nginx 
Replicas: 3 updated | 3 total | 3 available | 0 unavailabl 
e 
StrategyType: RollingUpdate 
MinReadySeconds: 0 
RollingUpdateStrategy: 1 max unavailable, 1 max surge 
OldReplicaSets: <none> 
NewReplicaSet: nginx-deployment-1564180365 (3/3 replicas cr 
eated) 
Events: 
FirstSeen LastSeen Count From Subobje 
ctPath Type Reason Message 
36s 36s 1 {deployment-controller } 
Normal ScalingReplicaSet Scaled up replica set n 
ginx-deployment - 2035384211 to 3 
23S 23s 1 {deployment-controller } 
Normal ScalingReplicaSet Scaled up replica set n 
ginx-deployment -1564180365 to 1 
23S 23s 1 {deployment-controller } 
Normal ScalingReplicaSet Scaled down replica set 
nginx-deployment - 2035384211 to 2 
23S 23s 1 {deployment-controller } 
Normal ScalingReplicaSet Scaled up replica set n 
ginx-deployment-1564180365 to 2 
21s 21s 1 {deployment-controller } 
Normal ScalingReplicaSet Scaled down replica set 
nginx-deployment - 2035384211 to 0 
21s 21s 1 {deployment-controller } 
Normal ScalingReplicaSet Scaled up replica set n 


ginx-deployment-1564180365 to 3 


我 们 可 以 看 到 当 我 们 刚 开 始 创建 这 个 Deployment 的 时 候 ， 创 建 了 一 个 
ReplicaSet (nginx-deployment-2035384211) ， 并 直接 扩容 到 了 3 个 replica ° 


当 我 们 更 新 这 个 Deployment 的 时 候 ， 它 会 创建 一 个 新 的 ReplicaSet (nginx- 
deployment-1564180365) ， 将 它 扩 容 到 1 个 replica， 然 后 缩 容 原先 的 ReplicaSet 
到 2 个 replica， 此 时 满足 至 少 2 个 Pod 是 可 用 状态 ， 同 一 时 刻 最 多 有 4 个 Pod 处 于 
创建 的 状态 。 


接着 继续 使 用 相同 的 rolling update 策略 扩容 新 的 ReplicaSet 和 缩 容 旧 的 
ReplicaSet。 最 终 ， 将 会 在 新 的 ReplicaSet 中 有 3 个 可 用 的 replica > 12 44 
ReplicaSet 的 replica 数目 变 成 0。 


Rollover ( 多 个 rollout 并 行 ) 


每 当 Deployment controller 观测 到 有 新 的 deployment 被 创建 时 ， 如 果 没 有 已 存在 
的 ReplicaSet 来 创建 期 望 个 数 的 Pod 的 话 ， 就 会 创建 出 一 个 新 的 ReplicaSet 来 做 
这 件 事 。 已 存在 的 ReplicaSet 控制 label 与 .spec.selector 匹配 但 是 template 
跟 .spec.template 不 匹配 的 Pod 缩 容 。 最 终 ， 新 的 ReplicaSet 将 会 扩容 

出 .spec.replicas 指定 数目 的 Pod， 昌 的 ReplicaSet 会 缩 容 到 0。 


如 果 您 更 新 了 一 个 的 已 存在 并 正在 进行 中 的 Deployment， 每 次 更 新 Deployment 都 
会 创建 一 个 新 的 ReplicaSet 并 扩容 它 ， 同 时 回 滚 之 前 扩容 的 ReplicaSet 一 一 将 它 
添加 到 昌 的 ReplicaSet 列表 中 ， 开 始 缩 容 。 


例如 ， 假 如 您 创建 了 一 个 有 5 个 niginx:1.7.9 replicas) Deployment， 但 是 当 还 
只 有 3 个 nginx:1.7.9 的 replica 创建 出 来 的 时 候 您 就 开始 更 新 含有 5 

个 nginx:1.9.1 replica 的 Deployment。 在 这 种 情况 下 ，Deployment 会 立即 杀 
掉 已 创建 的 3 个 nginx:1.7.9 的 Pod， 并 开始 创建 nginx:1.9.1 的 Pod。 它 不 
会 等 到 所 有 的 5 个 nginx:1.7.9 的 Pod 都 创建 完成 后 才 开 始 改变 航道 。 


Label selector 更 新 


我 们 通常 不 鼓励 更 新 label selector ， 我 们 建议 事先 规划 好 您 的 selector 。 


任何 情况 下 ， 只 要 您 想 要 执行 label selector 的 更 新 ， 请 一 定 要 谨 懂 并 确认 您 已 经 
预料 到 所 有 可 能 因此 导致 的 后 果 。 


e 增添 selector 需要 同时 在 Deployment 的 spec 中 更 新 新 的 label > 4 J| 3p 3& E 
校 验 错误 。 此 更 改 是 不 可 覆盖 的 ， 这 意味 着 新 的 selector 不 会 选择 使 用 旧 
selector 创建 的 ReplicaSet fe Pod， 从 而 导致 所 有 旧版 本 的 ReplicaSet 都 被 
丢弃 ， 并 创建 新 的 ReplicaSet 。 

e 更 新 selector， 即 更 改 selector key 的 当前 值 ， 将 导致 跟 增 添 selector 同样 的 
后 果 。 

e 删除 selector， 即 删除 Deployment selector 中 的 已 有 的 key， 不 需要 对 Pod 
template label 做 任何 更 改 ， 现 有 的 ReplicaSet 也 不 会 成 为 孤儿 ， 但 是 请 注 
意 ， 删 除 的 label 仍然 存在 于 现 有 的 Pod 和 ReplicaSet 中 。 


€ ik Deployment 


有 时 候 您 可 能 想 回 退 一 个 Deployment > #4 > 4 Deployment 不 稳定 时 ， 比 如 一 
直 crash looping ° 


默认 情况 下 ，kubernetes 会 在 系统 中 保存 前 两 次 的 Deployment 的 rollout 历史 记 
录 ， 以 便 您 可 以 随时 回 退 (您 可 以 修改 revision history limit 来 更 改 保存 的 
revision 数 ) 。 

注意 : 只 要 Deployment 的 rollout 被 触发 就 会 创建 一 个 revision。 也 就 是 说 当 且 仅 
3 Deployment 的 Pod template (如 .spec.template ) 被 更 改 ， 例 如 更 新 
template 中 的 label 和 容器 镜像 时 ， 就 会 创建 出 一 个 新 的 revision 。 





其 他 的 更 新 ， 比 如 扩容 Deployment 不 会 创建 revisio 
手动 或 者 自动 扩容 。 这 意味 着 当 您 回 退 到 历史 revision 时 ， 只 有 Deployment 中 的 
Pod template 部 分 才 会 回 退 


假设 我 们 在 更 新 Deployment 的 时 候 犯 了 一 个 拼写 错误 ， 将 镜像 的 名 字 写 成 
了 nginx:1.91 ， 而 正确 的 名 字 应 该 是 nginx:1.9.1 


$ kubectl set image deployment/nginx-deployment nginx=nginx:1.91 
deployment "nginx-deployment" image updated 


Rollout 将 会 卡 住 。 


$ kubectl rollout status deployments nginx-deployment 
Waiting for rollout to finish: 2 out of 3 new replicas have been 
updated... 


dfi Ctrl-C 4E. E do % rollout 状态 监控 。 


ft w 89 replica (nginx-deployment-1564180365 和 nginx-deployment- 
2035384211) 和 新 的 replica (nginx-deployment-3066724191) 数目 都 是 2 个 。 


$ kubectl get rs 


NAME DESIRED CURRENT READY AGE 
nginx-deployment-1564180365 2 2 0 25s 
nginx -deployment - 2035384211 0 0 0 36s 


nginx-deployment - 3066724191 2 2 2 6s 


看 下 创建 Pod， 您 会 看 到 有 两 个 新 的 ReplicaSet 创建 的 Pod 处 于 


ImagePullBackOff 状态 ， 循 环 拉 取 镜像 。 


$ kubectl get pods 
NAME 
RESTARTS AGE 


nginx -deployment -1564180365-70iae 
0 25S 
nginx-deployment -1564180365- jbqqo 
0 25s 
nginx-deployment - 3066724191 -08mng 
0 6s 
nginx-deployment-3066724191-eocby 
0 6s 


READY 


1/1 


1/1 


0/1 


0/1 


STATUS 

Running 

Running 
ImagePullBackOff 


ImagePullBackOff 


i£% » Deployment controller 会 自动 停止 坏 的 rollout， 并 停止 扩容 新 的 


ReplicaSet ° 


$ kubectl describe deployment 


Name: nginx-deployment 
Namespace: default 
CreationTimestamp: Tue, 15 Mar 2016 14:48:04 -0700 
Labels: app=nginx 
Selector: app=nginx 
Replicas: 2 updated | 3 total | 2 available | 2 unavailabl 
e 
StrategyType: RollingUpdate 
MinReadySeconds: 0 
RollingUpdateStrategy: 1 max unavailable, 1 max surge 
OldReplicaSets: nginx-deployment-1564180365 (2/2 replicas cr 
eated) 
NewReplicaSet: nginx-deployment -3066724191 (2/2 replicas cr 
eated) 
Events: 
FirstSeen LastSeen Count From Subobjec 
tPath Type Reason Message 
1m 1m 1 {deployment-controller } 
Normal ScalingReplicaSet Scaled up replica set ng 
inx-deployment - 2035384211 to 3 
22S 22s 1 {deployment-controller } 
Normal ScalingReplicaSet Scaled up replica set ng 
inx-deployment -1564180365 to 1 
22S 22s 1 {deployment-controller } 
Normal ScalingReplicaSet Scaled down replica set 
nginx-deployment - 2035384211 to 2 
22S 22s 1 {deployment-controller } 
Normal ScalingReplicaSet Scaled up replica set ng 
inx-deployment -1564180365 to 2 
21s 21s 1 {deployment-controller } 
Normal ScalingReplicaSet Scaled down replica set 
nginx-deployment - 2035384211 to 0 
21s 21s 1 {deployment-controller } 
Normal ScalingReplicaSet Scaled up replica set ng 
inx-deployment -1564180365 to 3 
13s 13s 1 {deployment-controller } 
Normal ScalingReplicaSet Scaled up replica set ng 
inx-deployment -3066724191 to 1 
13s 13s 1 {deployment-controller } 
Normal ScalingReplicaSet Scaled down replica set 
nginx-deployment-1564180365 to 2 
13s 13s 1 {deployment-controller } 
Normal ScalingReplicaSet Scaled up replica set ng 


inx-deployment -3066724191 to 2 


为 了 修复 这 个 问题 ， 我 们 需要 回 退 到 稳定 的 Deployment revision » 


检查 Deployment 升级 的 历史 记录 
首先 ， 检 查 下 Deployment 的 revision : 


$ kubectl rollout history deployment/nginx-deployment 
deployments "nginx-deployment": 
REVISION CHANGE - CAUSE 


1 kubectl create -f https://kubernetes.io/docs/user -gu 
ide/nginx-deployment.yaml--record 

2 kubectl set image deployment/nginx-deployment nginx- 
nginx:1.9.1 

3 kubectl set image deployment/nginx-deployment nginx- 
nginx:1.91 


因为 我 们 创建 Deployment 的 时 候 使 用 了 --record 参数 可 以 记录 命令 ， 我 们 可 以 
很 方便 的 查看 每 次 revision 的 变化 。 


查看 单个 revision 的 详细 信息 : 


$ kubectl rollout history deployment/nginx-deployment --revision= 
2 
deployments "nginx-deployment" revision 2 
Labels: app=nginx 
pod-template-hash=1159050644 
Annotations:  kubernetes.io/change-cause-kubectl set image dep 
loyment/nginx-deployment nginx-nginx:1.9.1 


Containers: 
nginx: 
Image: nginx:1.9.1 
Port: 80/TCP 
QoS Tier: 
cpu: BestEffort 
memory: BestEffort 
Environment Variables: <none> 


No volumes. 


J 
回 退 到 历史 版 本 
现在 ， 我 们 可 以 决定 回 退 当前 的 rollout 到 之 前 的 版 本 : 


$ kubectl rollout undo deployment/nginx-deployment 
deployment "nginx-deployment" rolled back 


也 可 以 使 用 --revision 参数 指定 某 个 历史 版 本 : 


$ kubectl rollout undo deployment/nginx-deployment --to-revision= 
2 
deployment "nginx-deployment" rolled back 


«| ami 








5 rollout 相关 的 命令 详细 文档 见 kubectl rollout 。 


该 Deployment 现在 已 经 回 退 到 了 先前 的 稳定 版 本 。 如 您 所 见 ，Deployment 
controller 产 生 了 一 个 回 退 到 revison 2 的 DeploymentRollback 的 event。 


$ kubectl get deployment 


NAME DESIRED CURRENT UP-TO-DATE AVAILABLE 
AGE 

nginx-deployment 3 3 3 3 

30m 


$ kubectl describe deployment 


Name: nginx-deployment 
Namespace: default 
CreationTimestamp: Tue, 15 Mar 2016 14:48:04 -0700 
Labels: app=nginx 
Selector: app=nginx 
Replicas: 3 updated | 3 total | 3 available | 0 unavailabl 
e 
StrategyType: RollingUpdate 
MinReadySeconds: 0 
RollingUpdateStrategy: 1 max unavailable, 1 max surge 
OldReplicaSets: <none> 
NewReplicaSet: nginx-deployment-1564180365 (3/3 replicas cr 
eated) 
Events: 
FirstSeen LastSeen Count From Subobjec 
tPath Type Reason Message 
30m 30m 1 {deployment-controller } 
Normal ScalingReplicaSet Scaled up replica set ng 
inx-deployment - 2035384211 to 3 
29m 29m 1 {deployment-controller } 
Normal ScalingReplicaSet Scaled up replica set ng 
inx-deployment -1564180365 to 1 
29m 29m 1 {deployment-controller } 
Normal ScalingReplicaSet Scaled down replica set 
nginx-deployment - 2035384211 to 2 
29m 29m 1 {deployment-controller } 
Normal ScalingReplicaSet Scaled up replica set ng 


inx-deployment -1564180365 to 2 


29m 29m 1 {deployment-controller } 


Normal ScalingReplicaSet Scaled down replica set 
nginx-deployment - 2035384211 to 0 
29m 29m 1 {deployment-controller } 
Normal ScalingReplicaSet Scaled up replica set ng 
inx-deployment -3066724191 to 2 
29m 29m 1 {deployment-controller } 
Normal ScalingReplicaSet Scaled up replica set ng 
inx-deployment -3066724191 to 1 
29m 29m 1 {deployment-controller } 
Normal ScalingReplicaSet Scaled down replica set 
nginx-deployment -1564180365 to 2 
2m 2m 1 {deployment-controller } 
Normal ScalingReplicaSet Scaled down replica set 
nginx-deployment - 3066724191 to 0 
2m 2m 1 {deployment-controller } 
Normal DeploymentRollback Rolled back deployment " 
nginx-deployment" to revision 2 
29m 2m 2 {deployment-controller } 
Normal ScalingReplicaSet Scaled up replica set ng 


inx-deployment -1564180365 to 3 


$3? Policy 


您 可 以 通过 设置 ,spec.revisonHistoryLimit 项 来 指定 deployment 最 多 保留 


少 revision 历史 记录 。 默 认 的 会 保留 所 有 的 revision ; 如 果 将 该 项 设置 为 0， 
Deployment 就 不 允许 回 退 了 。 


Deployment 扩容 
您 可 以 使 用 以 下 命令 扩容 Deployment : 


$ kubectl scale deployment nginx-deployment --replicas 10 
deployment "nginx-deployment" scaled 


假设 您 的 集群 中 启用 了 horizontal pod autoscaling， 您 可 以 给 Deployment 设置 一 
个 autoscaler， 基 于 当前 Pod 的 CPU 利用 率 选 LER 和 最 多 的 Pod 3k » 


$ kubectl autoscale deployment nginx-deployment --min=10 --max=1 


5 --cpu-percent-80 
deployment "nginx-deployment" autoscaled 


$ 


比例 扩容 


RollingUpdate Deployment 支持 同时 运行 一 个 应 用 的 多 个 版 本 。 或 者 autoscaler 4^ 
容 RollingUpdate Deployment 的 时 候 ， 正 在 中 途 的 rollout (进行 中 或 者 已 经 暂停 
的 ) ， 为 了 降低 风险 ，Deployment controller 将 会 平衡 已 存在 的 活动 中 的 
ReplicaSet (有 Pod 的 ReplicaSet) 和 新 加 入 的 replica。 这 被 称 为 比例 扩容 。 


例如 ， 您 正在 运行 中 含有 10 个 replica 的 Deployment » maxSurge=3 ， 
maxUnavailable=2 ° 


$ kubectl get deploy 


NAME DESIRED CURRENT UP-TO-DATE AVAILABLE 
AGE 

nginx-deployment 10 10 10 10 
50s 


您 更 新 了 一 个 镜像 ， 而 在 集群 内 部 无 法 解析 。 


$ kubectl set image deploy/nginx-deployment nginx=nginx:sometag 
deployment "nginx-deployment" image updated 


镜像 更 新 启动 了 一 个 包含 ReplicaSet nginx-deployment-1989198191 55 3 8j 
rollout， 但 是 它 被 阻塞 了 ， 因 为 我 们 上 面 提 到 的 maxUnavailable 。 


$ kubectl get rs 


NAME DESIRED CURRENT READY AGE 
nginx-deployment-1989198191 5 5 0 9s 
nginx-deployment-618515232 8 8 8 1m 


然后 发 起 了 一 个 新 的 Deployment 扩 容 请 求 。autoscaler 将 Deployment 的 repllica 数 

目 增加 到 了 15 个 。Deployment controller 需 要 判断 在 哪里 增加 这 5 个 新 的 replica。 如 
果 我 们 没有 谁 用 比例 扩容 ， 所 有 的 5 个 replica 都 会 加 到 一 个 新 的 ReplicaSet 中 。 如 果 
使 用 比例 扩容 ， 新 添加 的 replica 将 传播 到 所 有 的 ReplicaSet 中 。 大 的 部 分 加 入 
replica 数 最 多 的 ReplicaSet 中 ， 小 的 部 分 加 入 到 replica 数 少 的 ReplciaSet 中 。0 个 
replica 的 ReplicaSet 不 会 被 扩容 。 


在 我 们 上 面 的 例子 中 ， eee 日 的 ReplicaSet 中 ，2 个 replica 将 添加 到 
新 的 ReplicaSet 中 。rollout 进 程 最 终 会 将 所 有 的 replica 移 动 到 新 的 ReplicaSet 中 ， 假 
设 新 的 replica 成 为 健康 状态 。 


$ kubectl get deploy 


NAME DESIRED CURRENT UP-TO-DATE AVAILABLE 
AGE 
nginx-deployment 15 18 7 8 
7m 
$ kubectl get rs 
NAME DESIRED CURRENT READY AGE 
nginx-deployment-1989198191 7 7 0 7m 
nginx-deployment - 618515232 11 11 11 7m 


1 4% 42 T X Deployment 


您 可 以 在 发 出 一 次 或 多 次 更 新 前 暂停 一 个 Deployment， 然 后 再 恢复 它 。 这 样 您 就 
能 多 次 暂停 和 恢复 Deployment， 在 此 期 间 进 行 一 些 修复 工作 ， 而 不 会 发 出 不 必要 
的 rollout ° 


例如 使 用 刚刚 创建 Deployment : 


$ kubectl get deploy 


NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
nginx 3 3 3 3 1m 
[mkargaki@dhcpi29-211 kubernetes]$ kubectl get rs 

NAME DESIRED CURRENT READY AGE 

nginx -2142116321 3 3 3 1m 


使 用 以 下 命令 暂停 Deployment : 


$ kubectl rollout pause deployment/nginx-deployment 
deployment "nginx-deployment" paused 


然后 更 新 Deplyment 中 的 镜像 : 


$ kubectl set image deploy/nginx nginx=nginx:1.9.1 
deployment "nginx-deployment" image updated 


注意 新 的 rollout 启动 了 : 


$ kubectl rollout history deploy/nginx 
deployments "nginx" 

REVISION CHANGE -CAUSE 

1 <none> 


$ kubectl get rs 
NAME DESIRED CURRENT READY AGE 
nginx -2142116321 3 3 3 2m 


您 可 以 进行 任意 多 次 更 新 ， 例 如 更 新 使 用 的 资源 : 


$ kubectl set resources deployment nginx -c-nginx --limits-cpu-2 
00m, memor y=512Mi 
deployment "nginx" resource requirements updated 


Deployment 暂停 前 的 初始 状态 将 继续 它 的 功能 ， 而 不 会 对 Deployment 的 更 新 产 
生 任 何 影 响 ， 只 要 Deployment 是 暂停 的 。 


最 后 ， 恢 复 这 个 Deployment， 观 察 完 成 更 新 的 ReplicaSet 已 经 创建 出 来 了 : 


$ kubectl rollout resume deploy nginx 

deployment "nginx" resumed 

$ KUBECTL get rs -w 

NAME DESIRED CURRENT READY AGE 


nginx-2142116321 2 2 2 2m 
nginx-3926361531 2 2 0 6s 
nginx-3926361531 2 2 1 18s 
nginx-2142116321 1 2 2 2m 
nginx-2142116321 1 2 2 2m 
nginx-3926361531 3 2 1 18s 
nginx-3926361531 3 2 1 18s 
nginx-2142116321 1 1 1 2m 
nginx-3926361531 3 3 1 18s 
nginx-3926361531 3 3 2 19s 
nginx-2142116321 0 1 1 2m 
nginx - 2142116321 0 1 1 2m 
nginx -2142116321 0 0 0 2m 
nginx -3926361531 3 3 3 20s 
^C 

$ KUBECTL get rs 

NAME DESIRED CURRENT READY AGE 
nginx-2142116321 0 0 0 2m 
nginx -3926361531 3 3 3 28S 


注意 : ARR Deployment 之 前 您 无 法 回 退 一 个 已 经 暂停 的 Deployment » 


Deployment 状态 


Deployment 在 生命 周期 中 有 多 种 状态 。 在 创建 一 个 新 的 ReplicaSet 的 时 候 它 可 以 
X progressing 状态 complete 状态 ， 或 者 fail to progress KA » 


进行 中 的 Deployment 
Kubernetes 将 执行 过 下 列 任务 之 一 的 Deployment 标记 为 progressing 状态 : 


e Deployment 正在 创建 新 的 ReplicaSet 过 程 中 。 
e Deployment 正在 扩容 一 个 已 有 的 ReplicaSet 。 
e Deployment 正在 缩 容 一 个 已 有 的 ReplicaSet 。 
e 有 新 的 可 用 的 pod 出 现 。 


您 可 以 使 用 kubectl rollout status 命令 监控 Deployment 的 进度 。 


完成 的 Deployment 
Kubernetes 将 包括 以 下 特性 的 Deployment 标记 为 complete 状态 : 


e Deployment 最 小 可 用 。 最 小 可 用 意味 着 Deployment 的 可 用 replica 个 数 等 于 
或 者 超过 Deployment 策略 中 的 期 望 个 数 。 

e 所 有 与 该 Deployment 相关 的 replica 都 被 更 新 到 了 您 指定 版 本 ， 也 就 说 更 新 完 
Re 

e. 该 Deployment F 2t Zj 19% Pod 存在 。 


您 可 以 用 kubectl rollout status 命令 查看 Deployment 是 否 完 成 。 如 果 
rollout 成 功 完成 ， kubectl rollout status 将 返回 一 个 0 值 的 Exit Code ° 


$ kubectl rollout status deploy/nginx 

Waiting for rollout to finish: 2 of 3 updated replicas are avail 
able... 

deployment "nginx" successfully rolled out 

$ echo $? 

0 


失败 的 Deployment 


您 的 Deployment 在 尝试 部 署 新 的 ReplicaSet 的 时 候 可 能 卡 住 ， 永 远 也 不 会 完成 。 
这 可 能 是 因为 以 下 几 个 因素 引起 的 : 


e 无 效 的 引用 

e 不 可 读 的 probe failure 
e 镜像 拉 取 错误 

e 权限 不 够 

e 范围 限制 

e 程序 运行 时 配置 错误 


探测 这 种 情况 的 一 种 方式 是 ， 在 您 的 Deployment spec 中 指 

定 spec.progressDeadlineSeconds ° spec.progressDeadlineSeconds 表示 
Deployment controller 等 待 多 少 秒 才能 确定 (通过 Deployment status) 
Deployment 进 程 是 卡 住 的 。 


下 面 的 kubectl 命令 设置 progressDeadlineSeconds 使 controller 在 
Deployment 在 进度 卡 住 10 分 钟 后 报告 : 


$ kubectl patch deployment/nginx-deployment -p '{"spec":{"progre 
ssDeadlineSeconds":600}}' 
"nginx-deployment" patched 


3 48 it A iE" RBS Deployment controller 会 在 Deployment 的 
status.conditions 中 增加 一 条 DeploymentCondition， 它 包括 如 下 属性 : 


e Type=Progressing 
e Status=False 
e Reason=ProgressDeadlineExceeded 


We 


浏览 Kubernetes API conventions #4 X T status conditions?) € £ 43 & » 


注意 : kubernetes!& f 4&4 Reason-ProgressDeadlineExceeded 状态 信息 外 不 
会 对 卡 住 的 Deployment 做 任何 操作 。 更 高 层次 的 协调 器 可 以 利用 它 并 采取 相应 行 
动 ， 例 如 ， 回 滚 Deployment 到 之 前 的 版 本 。 


注意 : 如 果 您 暂停 了 一 个 Deployment， 在 暂停 的 这 段 时 间 内 kubernetnes 不 会 检查 
您 指定 的 deadline。 您 可 以 在 Deployment 的 rollout 途中 安全 的 暂停 它 ， 然 后 再 恢 
复 它 ， 这 不 会 触发 超过 deadline 的 状态 。 


您 可 能 在 使 用 Deployment 的 时 候 遇 到 一 些 短暂 的 错误 ， 这 些 可 能 是 由 于 您 设置 了 
太 短 的 timeout， 也 有 可 能 是 因为 各 种 其 他 错误 导致 的 短暂 错误 。 例 如 ， 假 设 您 使 
用 了 无 效 的 引用 。 当 您 Describe Deployment 的 时 候 可 能 会 注意 到 如 下 信息 : 


$ kubectl describe deployment nginx-deployment 


SS 

Conditions: 
Type Status Reason 
Available True MinimumReplicasAvailable 
Progressing True ReplicaSetUpdated 
ReplicaFailure True FailedCreate 

oe ae 


执行 kubectl get deployment nginx-deployment -o yaml ^» Deployement 
的 状态 可 能 看 起 来 像 这 个 样子 : 


status: 
availableReplicas: 2 
conditions: 
- lastTransitionTime: 2016-10-04T12:25:39Z 
lastUpdateTime: 2016-10-04T12:25:39Z 
message: Replica set "nginx-deployment-4262182780" is progre 
ssing. 
reason: ReplicaSetUpdated 
status: "True" 
type: Progressing 
- lastTransitionTime: 2016-10-04T12:25:42Z 
lastUpdateTime: 2016-10-04T12:25:42Z 
message: Deployment has minimum availability. 
reason: MinimumReplicasAvailable 
status: "True" 
type: Available 
- lastTransitionTime: 2016-10-04T12:25:39Z 
lastUpdateTime: 2016-10-04T12:25:39Z 
message: 'Error creating: pods "nginx-deployment-4262182780- 
" is forbidden: exceeded quota: 
object-counts, requested: pods=1, used: pods-3, limited: p 
ods=2' 
reason: FailedCreate 
status: "True" 
type: ReplicaFailure 
observedGeneration: 3 
replicas: 2 
unavailableReplicas: 2 


最 终 ， 一 旦 超过 Deployment 进程 的 deadline > kuberentes 会 更 新 状态 和 导致 
Progressing 状态 的 原因 : 


Conditions: 
Type Status Reason 
Available True MinimumReplicasAvailable 
Progressing False ProgressDeadlineExceeded 
ReplicaFailure True FailedCreate 


您 可 以 通过 缩 容 Deployment 的 方式 解决 配额 不 足 的 问题 ， 或 者 增加 您 的 
namespace 的 配额 。 如 果 您 满足 了 配额 条 件 后 ，Deployment controller 就 会 完成 
您 的 Deployment rollout， 您 将 看 到 Deployment 的 状态 更 新 为 成 功 状态 

( Status=True 并 且 Reason-NewReplicaSetAvailable ) » 


Conditions: 
Type Status Reason 
Available True MinimumReplicasAvailable 
Progressing True NewReplicaSetAvailable 


Type=Available ^ Status=True 以 为 这 您 的 Deployment 有 最 小 可 用 性 。 最 
小 可 用 性 是 在 Deployment 策 略 中 指定 的 参数 。 Type=Progressing 、 
Status=True 意味 着 您 的 Deployment 或 者 在 部 署 过 程 中 ， 或 者 已 经 成 功 部 署 ， 
达到 了 期 望 的 最 少 的 可 用 replica 数 量 (查看 特定 状态 的 Reason 一 一 在 我 们 的 例子 
中 Reason=NewReplicaSetAvailable 意味 着 Deployment 已 经 完成 ) 。 


您 可 以 使 用 kubectl rollout status 命令 查看 Deployment 进 程 是 否 失败 。 当 
Deployment 过 程 超过 了 deadline， kubectl rollout status 将 返回 非 0 的 exit 
code ° 


$ kubectl rollout status deploy/nginx 

Waiting for rollout to finish: 2 out of 3 new replicas have been 
updated... 

error: deployment "nginx" exceeded its progress deadline 

$ echo $? 

1 


操作 失败 的 Deployment 


所 有 对 完成 的 Deployment 的 操作 都 适用 于 失败 的 Deployment。 您 可 以 对 它 扩 / 缩 


容 ， 回 退 到 历史 版 本 ， 您 其 至 可 以 多 次 暂停 它 来 应 用 Deployment pod template 。 


清理 Policy 


您 可 以 设置 Deployment 中 的 ,spec.revisionHistoryLimit 项 来 指定 保留 多 少 
日 的 ReplicaSet 。 余下 的 将 在 后 台 被 当 作 垃圾 收集 。 黑 认 的 ， 所 有 的 revision 历史 
就 都 会 被 保留 。 在 未 来 的 版 本 中 ， 将 会 更 改 为 2。 

注意 : 将 该 值 设置 为 0， 将 导致 所 有 的 Deployment 历史 记录 都 会 被 清除 ， 该 
Deployment 就 无 法 再 回 退 了 。 


用 例 


4: % 4 Deployment 


如 果 您 想 要 使 用 Deployment 对 部 分 用 户 或 服务 器 发 布 release， 您 可 以 创建 多 个 
ig 


Deployment * 每 个 Deployment 对 应 一 个 release * 48 managing resources 中 对 
B EIR KA 19 Aw ik © 


编写 Deployment Spec 


在 所 有 的 Kubernetes BG E  » Deployment 也 需 
要 apiVersion * kind 和 metadata 这 些 配置 项 。 配 置 文件 的 通用 使 用 说 明 查 
看 部 署 应 用 ， 配 置 容器 ， 和 使 用 kubectl 管理 资源 文档 。 


Deployment 也 需要 .spec section. 


Pod Template 


.spec.template 是 .spec 中 唯一 要 求 的 字段 。 


Se 


.spec.template Æ pod template. ESR Pod —7##—# fdschema > R T ÆR 
套 的 并 且 不 需要 apiversion 和 kind 字段 。 


另外 为 了 划分 Pod 的 范围 ，Deployment 中 的 pod template 必 须 指定 适当 的 label (不 
要 跟 其 他 controller 重 复 了 ， 参 考 selector) 和 适当 的 重启 策略 。 


.spec.template.spec.restartPolicy 可 以 设置 为 Always ,如 果 不 指定 的 话 
这 就 是 默认 配置 


Replicas 


.spec.replicas 是 可 以 选 字段 ， 指 定期 望 的 pod 数 量 ， 默 认 是 1。 


Selector 


.spec.selector 是 可 选 字段 ， 用 来 指定 label selector ， 圈 定 Deployment 管 理 的 
pod 范 围 。 


如 果 被 指定 ， .spec.selector 必须 匹配 
,Spec.template.metadata.labels ， 和 否则 它 将 被 API 拒 绝 。 如 果 
.spec.selector 没有 被 指定 ， .spec.selector.matchLabels 默认 是 


.spec.template.metadata.labels “。 


在 Pod 的 template 跟 .spec.template 不 同 或 者 数量 超过 了 .spec.replicas 规 
定 的 数量 的 情况 下 ，Deployment 会 杀 掉 label 跟 selector 不 同 的 Pod。 


注意 : 您 不 应 该 再 创建 其 他 label 跟 这 个 selector 匹 配 的 pod， 或 者 通过 其 他 
Deployment， 或 者 通过 其 他 Controller > oe ° 
否则 该 Deployment 会 被 把 它们 当成 都 是 自己 创建 的 。Kubernetes 不 会 阻止 您 这 

做 。 


如 果 您 有 多 个 controller 使 用 了 重复 的 selector ，controller 们 就 会 互相 打架 并 导致 不 
正确 的 行为 。 


大 大 
FG 

.spec.strategy 指定 新 的 Pod 替 换 昌 的 Pod 的 策略 。 .spec.strategy.type 
可 以 是 "Recreate" 或 者 是 "RollingUpdate"。"RollingUpdate" 是 默认 值 。 
Recreate Deployment 


.spec.strategy.type--Recreate 时 ， 在 创建 出 新 的 Pod 之 前 会 先 杀 掉 所 有 已 存 
在 的 Pod 。 


Rolling Update Deployment 


.spec.strategy.type==RollingUpdate H1 > Deploymentt# M rolling update 的 
方式 更 新 Pod 。 您 可 以 指定 maxUnavailable 和 maxSurge 来 控制 rolling 
Update 进程 。 


Max Unavailable 


.spec.strategy.rollingUpdate.maxUnavailable 是 可 选 配置 项 ， 用 来 指定 在 
升级 过 程 中 不 可 用 Pod 的 最 大 数量 。 该 值 可 以 是 一 个 绝对 值 (例如 5) ， 也 可 以 是 期 
望 Pod 数 量 的 百分比 【例如 10% ) 。 通 过 计算 百分比 的 绝对 值 向 下 取 整 。 如 
A .spec.strategy.rollingUpdate.maxSurge 为 0 时 ， 这 个 值 不 可 以 为 0°。 默认 
值 是 1。 


例如 ， 该 值 设 置 成 30%， 启 动 rolling update% Œ 4) ReplicatSet44 2 = Bp 4a X £] 3] 37 
的 Pod 数 量 的 70%。 新 的 Pod ready 后 ， 随 着 新 的 ReplicaSet 的 扩容 ， 昌 的 
ReplicaSet 会 进一步 缩 容 ， 确 保 在 升级 的 所 有 时 刻 可 以 用 的 Pod 数 量 至 少 是 期 望 Pod 
数量 的 70% © 


Max Surge 


.spec.strategy.rollingUpdate.maxsurge 是 可 选 配 置 项 ， 用 来 指定 可 以 超过 
期 望 的 Pod 数 量 的 最 大 个 数 。 该 值 可 以 是 一 个 绝对 值 (例如 5) 或 者 是 期 望 的 Pod 数 
量 的 百分比 (例如 10%) 。 当 Maxunavailable 为 0 时 该 值 不 可 以 为 0。 通过 百 分 
比 计 算 的 绝对 值 向 上 取 整 。 默 认 值 是 1。 


例如 ， 该 值 设 置 成 30%， 启 动 rolling update 后 新 的 ReplicatSet 将 会 立即 扩容 ， 新 老 
Pod 的 总 数 不 能 超过 期 望 的 Pod 数 量 的 130%。 曙 的 Pod 被 杀 掉 后 ， 新 的 ReplicaSet 

将 继续 扩容 ， 旧 的 ReplicaSet 会 进一步 缩 容 ， 确 保 在 升级 的 所 有 时 刻 所 有 的 Pod 数 

量 和 不 会 超过 期 望 Pod 数 量 的 130% ° 


Progress Deadline Seconds 


.spec.progressDeadlineSeconds 是 可 选 配 置 项 ， 用 来 指定 在 系统 报告 
Deployment 的 failed progressing 一 一 表现 为 resource 的 状态 
中 type-Progressing ^ Status=False ^ 


Reason=ProgressDeadlineExceeded 前 可 以 等 待 的 Deployment 进 行 的 秒 数 。 
Deployment controller 会 继续 重 试 该 Deployment。 未 来 ， 在 实现 了 自动 回 滚 后 ， 
deployment controller 在 观察 到 这 种 状态 时 就 会 自动 回 滚 。 


如 果 设 置 该 参数 ， 该 值 必 须 大 于 .spec.minReadySeconds ° 


Min Ready Seconds 


.spec.minReadySeconds 是 一 个 可 选 配 置 项 ， 用 来 指定 没有 任何 容器 crash 的 
Pod 并 被 认为 是 可 用 状态 的 最 小 秒 数 。 默 认 是 0 (Pod 在 ready 后 就 会 被 认为 是 可 用 
KA) 。 进 一 步 了 解 什么 什么 后 Pod 会 被 认为 是 ready 状 态 ， 参 阅 Container 
Probes » 


Rollback To 


.spec.rollbackTo 是 一 个 可 以 选 配 置 项 ， 用 来 配置 Deployment 回 退 的 配置 。 设 
置 该 参数 将 触发 回 退 操作 ， 每 次 回 退 完成 后 ， 该 值 就 会 被 清除 。 


Revision 


.spec.rollbackTo.revision 是 一 个 可 选 配 置 项 ， 用 来 指定 回 退 到 的 revision。 
默认 是 0， 意 味 着 回 退 到 上 一 个 revision 。 


Revision History Limit 
Deployment revision history # fi # © 4€ #] 49 ReplicaSets  » 


.spec.revisionHistoryLimit 是 一 个 可 选 配 置 项 ， 用 来 指定 可 以 保留 的 昌 的 
ReplicaSet 数 量 。 该 理想 值 取决 于 心 Deployment 的 频 座 和 稳定 性 。 如 果 该 值 没 有 设 
置 的 话 ， 黑 认 所 有 目的 Replicaset 或 会 被 保留 ， 将 资源 存储 在 etcd 中 ， 是 
用 kubectl get rs 查看 输出 。 每 个 Deployment 的 该 配置 都 保存 在 ReplicaSet 
中 ， 然 而 ， 一 旦 您 删除 的 昌 的 RepelicaSet， 您 的 Deployment 就 无 法 再 回 退 到 那个 
revison 7 ° 


如 果 您 将 该 值 设置 为 0， 所 有 具有 0 个 replica 的 ReplicaSet 都 会 被 删除 。 在 这 种 情况 
下 ， 新 的 Deployment rollout 无 法 撤销 ， 因 为 revision history 都 被 清理 掉 了 。 


Paused 


.spec.paused 是 可 以 可 选 配置 项 ，boolean 值 。 用 来 指定 暂停 和 恢复 
Deployment。Paused 和 没有 paused 的 Deployment 之 间 的 唯一 区 别 就 是 ， 所 有 对 
paused deployment 中 的 PodTemplateSpec 的 修改 都 不 会 触发 新 的 rollout 。 
Deployment 被 创建 之 后 默认 是 非 paused ° 


Deployment 的 替代 选择 


kubectl rolling update 


Kubectl rolling update 虽然 使 用 类 似 的 方式 更 新 Pod 和 ReplicationController。 但 是 
我 们 推荐 使 用 Deployment， 因 为 它 是 声明 式 的 ， 客 户 端 侧 ， 具 有 附加 特性 ， 例 如 即 
使 滚动 升级 结束 后 也 可 以 回 滚 到 任何 历史 版 本 。 
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StatefulSet 


StatefulSet 作为 Controller A Pod 提供 唯一 的 标识 。 它 可 以 保证 部 署 和 scale 的 顺 
Fe o 


使 用 案例 参考 : kubernetes contrib - statefulsets > X- F & 2 zookeeperfekakfa fj 
statefulset 设 置 和 使 用 说 明 。 


StatefulSet 是 为 了 解决 有 状态 服务 的 问题 (对 应 Deployments 和 ReplicaSets 是 为 无 
状态 服务 而 设计 ) ， 其 应 用 场景 包括 : 


e 稳定 的 持久 化 存储 ， 即 Pod 重 新 调度 后 还 是 能 访问 到 相同 的 持久 化 数据 ， 基 于 
PVC 来 实现 

e 稳定 的 网 络 标志 ， 即 Pod 重 新 调度 后 其 PodName 和 HostName 不 变 ， 基 于 
Headless Service ( 即 没 有 Cluster IP 的 Service) 来 实现 

e. 有 序 部 署 ， 有 序 扩展 ， 即 Pod 是 有 顺序 的 ， 在 部 署 或 者 扩展 的 时 候 要 依据 定义 
的 顺序 依次 依次 进行 ( 即 从 0 到 N-1， 在 下 一 个 Pod 运 行 之 前 所 有 之 前 的 Pod 必 
须 都 是 Running 和 Ready 状 态 ) ， 基 于 init containers 来 实现 

e 有 序 收缩 ， 有 序 删除 〈 即 从 N-1 到 0 ) 


从 上 面 的 应 用 场景 可 以 发 现 ，StatefulSet 由 以 下 几 个 部 分 组 成 : 


e 用 于 定义 网 络 标志 (DNS domain) 的 Headless Service 
e 用 于 创建 PersistentVolumes 的 volumeClaimTemplates 
e 定义 具体 应 用 的 StatefulSet 


StatefulSet 中 每 个 Pod 的 DNS 格式 为 statefulSetName-{0..N- 


1}.serviceName.namespace.svc.cluster.local ， 其 中 


e serviceName 为 Headless Service 的 名 字 

e 0..N-1 为 Pod 所 在 的 序号 ， 从 0 开始 到 N-1 

e statefulSetName 为 StatefulSet 的 名 字 

e namespace 为 服务 所 在 的 namespace，Headless Servic 和 StatefulSet 必 须 在 
相同 的 namespace 

e .cluster.local 为 Cluster Domain 


使 用 StatefulSet 


StatefulSet 适用 于 有 以 下 某 个 或 多 个 需求 的 应 用 : 


e 稳定 ， 唯 一 的 网 络 标志 。 

e 稳定 ， 持 久 化 存储 。 

e 有 序 ， 优 雅 地 部 署 和 scale 。 
e 有 序 ， 优 雅 地 删除 和 终止 。 
e 有 序 ， 自 动 的 滚动 升级 。 


在 上 文中 ， 稳 定 是 Pod (重新 ) 调度 中 持久 性 的 代名词 。 如 果 应 用 程序 不 需要 任 
何 稳定 的 标识 符 、 有 序 部 署 、 删 除 和 scale， 则 应 该 使 用 提供 一 组 无 状态 副本 的 
controller 来 部 署 应 用 程序 ， 例 如 Deployment 或 ReplicaSet 可 能 更 适合 您 的 无 状 


限制 


e StatefulSet 是 beta 资源 ，Kubernetes 1.5 以 前 版 本 不 支持 。 

e 对 于 所 有 的 alpha/beta 的 资源 ， 您 都 可 以 通过 在 apiserver 中 设置 -- 
runtime-config 选项 来 禁用 。 

e 给 定 Pod 的 存储 必须 由 PersistentVolume Provisioner 根据 请 求 的 ”storage 
class 进行 配置 ， 或 由 管理 员 预 先 配置 。 

e 删除 或 scale StatefulSet 将 不 会 删除 与 StatefulSet 相关 联 的 volume 。 这 样 做 

是 为 了 确保 数据 安全 性 ， 这 通常 比 自动 清除 所 有 相关 StatefulSet 资源 更 有 价 

值 。 

StatefulSets 目前 要 求 Headless Service 负责 Pod 的 网 络 身份 。 您 有 责任 创 

建 此 服务 。 


组 件 


下 面 的 示例 中 描述 了 StatefulSet 中 的 组 件 。 


e 一 个 名 为 nginx 的 headless service， 用 于 控制 网 络 域 。 

e 一 个 名 为 web 的 StatefulSet， 它 的 Spec 中 指定 在 有 3 个 运行 nginx 容器 的 
Pod ° 

e volumeClaimTemplates 使 用 PersistentVolume Provisioner 提供 的 
PersistentVolumes 作为 稳定 存储 。 


StatefulSet 


apiVersion: v1 
kind: Service 


metadata: 
name: nginx 
labels: 
app: nginx 
spec: 
ports: 
- port: 80 
name: web 
clusterIP: None 
selector: 


app: nginx 
apiVersion: apps/vibetai 
kind: StatefulSet 
metadata: 
name: web 
spec: 
serviceName: "nginx" 
replicas: 3 
template: 
metadata: 
labels: 
app: nginx 
spec: 
terminationGracePeriodSeconds: 10 
containers: 
- name: nginx 


image: gcr.io/google containers/nginx-slim:0.8 


ports: 
- containerPort: 80 
name: web 
volumeMounts: 
- name: www 
mountPath: /usr/share/nginx/html 
volumeClaimTemplates: 
- metadata: 
name: www 
annotations: 


volume.beta.kubernetes.io/storage-class: 


spec: 
accessModes: [ "ReadWriteOnce" ] 
resources: 
requests: 
storage: 16i 


Pod 身份 


anything 
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StatefulSet Pod 具有 唯一 的 身份 ， 包 括 序 数 ， 稳 定 的 网 络 身份 和 稳定 的 存储 。 身 
份 绑 定 到 Pod b» REE (FH) 7 5 o 


序数 


对 于 一 个 有 N 个 副本 的 StatefulSet， 每 个 副本 都 会 被 指定 一 个 整数 序数 ， 在 [0,N) 
之 间 ， 且 唯一 。 


& 定 的 网 络 ID 


StatefulSet 中 的 每 个 Pod 从 StatefulSet 的 名 称 和 Pod 的 序数 派生 其 主机 名 。 构 造 
的 主机 名 的 模式 是 $ (statefulset 名 称 )-$( 序 数 ) 。 上 面 的 例子 将 创建 三 个 名 
为 web-@° web-1°web-2 的 Pod» 


StatefulSet 可 以 使 用 Headless Service 来 控制 其 Pod 的 域 。 此 服务 管理 的 域 的 格 
KA: $( 服 务 名 称 ) .$(namespace).svc.cluster.local ， 其 中 “cluster.local” 是 
集群 域 。 


在 创建 每 个 Pod 时 ， 它 将 获取 一 个 匹配 的 DNS 子 域 ， 采 用 以 下 形式 : $(pod 名 
称 ) .$( 管 理 服务 域 ) ， 其 中 管理 服务 由 StatefulSet 上 的 ”serviceName 字段 定 
X. o 


以 下 是 Cluster Domain » AR 42 fk > StatefulSet 名 称 以 及 如 何 影 响 StatefulSet 的 
Pod 的 DNS 名 称 的 一 些 示例 。 


Cluster Service StatefulSet StatefulSet Domain 

Domain (ns/name) (ns/name) 
cluster.local default/nginx default/web —nginx.default.svc.cluster.local a 
cluster.local foo/nginx foo/web nginx.foo.svc.cluster.local 
kube.local foo/nginx foo/web nginx.foo.svc.kube.local i 


注意 Cluster Domain 将 被 设置 成 cluster.local 除非 进行 了 其 他 配置 。 


稳定 存储 


Kubernetes 为 每 个 VolumeClaimTemplate 创建 一 个 PersistentVolume ° Ewa) 
nginx 的 例子 中 ， 每 个 Pod 将 具有 一 个 由 anything 存储 类 创建 的 1GB 存储 的 
PersistentVolume ° 3% Pod (重新 ) 调度 到 节点 上 ， volumeMounts 将 挂 载 与 
PersistentVolume Claim 相关 联 的 PersistentVolume。 请 注意 ， 与 
PersistentVolume Claim 相关 联 的 PersistentVolume 在 产 出 Pod 或 StatefulSet 的 
时 候 不 会 被 删除 。 这 必须 手动 完成 。 


部 署 和 Scale 保证 


e 对 于 有 N 个 副本 的 StatefulSet，Pod 将 按照 {0..N-1} 的 顺序 被 创建 和 部 署 。 
o Z 删除 Pod 的 时 候 ， 将 按照 逆序 来 终结 ， 从 {N-1..0} 
e 对 Pod 执行 scale 操作 之 前 ， 它 所 有 的 前 任 必 须 处 于 Running 和 Ready 状 


e 在 终止 Pod 前 ， 它 所 有 的 继任 者 必须 处 于 完全 关闭 状态 。 


不 应 该 将 StatefulSet 的 pod.Spec.TerminationGracePeriodSeconds 设置 为 
这 样 是 不 安全 的 且 强 烈 不 建议 您 这 样 做 。 进 一 步 解 释 ， 请 参阅 强制 删除 
StatefulSet Pod ° 


上 面 的 nginx 示例 创建 后 ，3 个 Pod 将 按照 如 下 顺序 创建 web-0 > web-1 > web- 
2。 在 web-0 处 于 运行 并 就 绪 状态 之 前 ，wWeb-1 将 不 会 被 部 署 ， 同 样 当 web-1 处 
于 运行 并 就 绪 状 态 之 前 Web-2 也 不 会 被 部 署 。 如 果 在 web-1 运行 并 就 绪 后 ，web-2 
启动 之 前 ，Web-0 ART » web-2 将 不 会 启动 ， 直 到 web-0 成 功 重启 并 处 于 运行 
并 就 绪 状 态 。 


如 果 用 户 通过 修补 StatefulSet 来 scale 部 署 的 示例 ， 以 使 replicas=1 > M 
web-2 将 首先 被 终止 。 在 Web-2 完全 关闭 和 删除 之 前 ，Web-1 不 会 被 终止 。 如 果 
web-0 在 web-2 终止 并 且 完 全 关闭 之 后 ， 但 是 在 web-1 终止 之 前 失败 ， 则 web-1 
将 不 会 终止 ， 除 非 web-0 正在 运行 并 准备 就 绪 。 


Pod 管理 策略 


在 Kubernetes 1.7 和 之 后 版 本 ，StatefulSet 允许 您 放 开 顺序 保证 ， 同 时 通过 
.Spec.podManagementPolicy 字段 保证 身份 的 唯一 性 。 


OrderedReady Pod 管理 


StatefulSet 中 默认 使 用 的 是 OrderedReady pod 管理 。 它 实现 了 如 上 所 述 的 行 
3 o 


并 行 Pod 管理 


Parallel pod 管理 告诉 StatefulSet controller #4749 È M 终止 Pod， 在 启动 
和 终止 其 他 Pod 之 前 不 会 等 待 Pod 变 成 运行 并 就 绪 或 完全 终止 状态 。 


更 新 策略 


在 kubernetes 1.7 和 以 上 版 本 中 ，StatefulSet 49 .spec.updatestrategy 字段 
允许 您 配置 和 禁用 StatefulSet 中 的 容器 、label、resource request/limit ` 
annotation 的 滚动 更 新 。 


OnDelete 更 新 策略 实现 了 遗留 (1.6 和 以 前 ) 的 行为 。 当 
spec.updateStrategy 未 指定 时 ， 这 是 默认 策略 。 4StatefulSet 的 
.spec.updateStrategy.type 设置 为 OnDelete 时 ，StatefulSet 控制 器 将 不 
会 自动 更 新 StatefulSet 中 的 Pode 用户 必须 手动 删除 Pod 以 使 控制 器 创建 新 
的 Pod， 以 反映 对 StatefulSet 的 .spec.template 进行 的 修改 。 


滚动 更 新 


RollingUpdate 更 新 策略 在 StatefulSet 中 实现 Pod 的 自动 滚动 更 新 。 当 
StatefulSet 的 .spec.updateStrategy.type 设置 为 RollingUpdate 时 ， 
StatefulSet 控制 器 将 在 StatefulSet 中 删除 并 新 创建 每 个 Pod。 它 将 以 与 Pod 终 
止 相 同 的 顺序 进行 (从 最 大 的 序数 到 最 小 的 序数 ) ， 每 次 更 新 一 个 Pod» 在 更 新 其 
前 身 之 前 ， 它 将 等 待 正 在 更 新 的 Pod 状态 变 成 正在 运行 并 就 绪 。 


分 区 


可 以 通过 指定 .spec.updateStrategy.rollingUpdate.partition 来 对 
RollingUpdate 更 新 策略 进行 分 区 。 Se 了 分 区 ， 则 当 StatefulSet 的 
.spec.template 更 新 时 ， 具 有 大 于 或 等 于 分 区 序数 的 所 有 Pod 将 被 更 新 。 具 有 


小 于 分 区 的 序数 的 所 有 Pod 将 不 会 被 更 新 ， 即 使 删除 它们 也 将 被 重新 创建 。 如 果 
StatefulSet 的 .spec.updatestrategy.rollingUpdate.partition 大 于 其 
.spec.replicas ， 则 其 .spec.template 的 更 新 将 不 会 传播 到 Pod ^ 


在 大 多 数 情 况 下 ， 您 不 需要 使 用 分 区 ， 但 如 果 您 想 要 进行 分 阶段 更 新 ， 使 用 金 丝 稚 
发 布 或 执行 分 阶段 发 布 ， 它 们 将 非常 有 用 。 


简单 示例 


以 一 个 简单 的 nginx 服 务 web.yam| 为 例 : 


StatefulSet 


apiVersion: vi 
kind: Service 


metadata: 
name: nginx 
labels: 
app: nginx 
spec: 
ports: 
- port: 80 
name: web 
clusterIP: None 
selector: 


app: nginx 
apiVersion: apps/vibetai 
kind: StatefulSet 
metadata: 
name: web 
spec: 
serviceName: "nginx" 
replicas: 2 
template: 
metadata: 
labels: 
app: nginx 
spec: 
containers: 
- name: nginx 


image: gcr.io/google containers/nginx-slim:0.8 


ports: 
- containerPort: 80 
name: web 
volumeMounts: 
- name: www 
mountPath: /usr/share/nginx/html 
volumeClaimTemplates: 
- metadata: 
name: www 
annotations: 


volume.alpha.kubernetes.io/storage-class: 


spec: 
accessModes: [ "ReadWriteOnce" ] 
resources: 
requests: 
storage: 16i 


anything 
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$ kubectl create -f web.yaml 
service "nginx" created 
statefulset "web" created 


# 查看 创建 的 headless servicefdestatefulset 
$ kubectl get service nginx 


NAME CLUSTER-IP EXTERNAL - IP PORT(S) AGE 
nginx None <none> 80/TCP 1m 
$ kubectl get statefulset web 

NAME DESIRED CURRENT AGE 

web 2 2 2m 


# 根据 volumeClaimTemplates 自 动 创建 PVC (在 GCE 中 会 自动 创建 kubernetes.io 
HK Fi 


/gce - pd && # volume) 
$ kubectl get pvc 


NAME STATUS VOLUME 
CAPACITY ACCESSMODES AGE 

WWW - web - 0 Bound pvc-d064a004-d8d4-11e6-b521-42010a800002 
16i RWO 16s 

WWw - web - 1 Bound pvc -d06a3946 -d8d4-11e6-b521-42010a800002 
1Gi RWO 16s 

# 查看 创建 的 Poq， 他 们 都 是 有 序 的 

$ kubectl get pods -1 app=nginx 

NAME READY STATUS RESTARTS AGE 

web -0 1/1 Running 0 5m 

web -1 1/1 Running 0 4m 


# 使 用 nslookup 查 看 这 些 Pod 的 DNS 
$ kubectl run -i --tty --image busybox dns-test --restart=Never 


--rm /bin/sh 
/ # nslookup web-0.nginx 
Server: 10.0.0.10 


Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local 


Name: web-0.nginx 

Address 1: 10.244.2.10 

/ # nslookup web-1.nginx 

Server: 10.0.0.10 

Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local 


Name: web-1.nginx 

Address 1: 10.244.3.12 

/ # nslookup web-0.nginx.default.svc.cluster.local 

Server: 10.0.0.10 

Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local 


Name: web-0.nginx.default.svc.cluster.local 
Address 1: 10.244.2.10 


还 可 以 进行 其 他 的 操作 


# 扩容 
$ kubectl scale statefulset web --replicas=5 


# 缩 容 

$ kubectl patch statefulset web -p '{"spec":{"replicas":3}}' 

# 镜像 更 新 (目前 还 不 支持 直接 更 新 Image， 需 要 Datch 来 间接 实现 ) 

$ kubectl patch statefulset web --type='json' -p='[{"op": "repla 


ce", "path": "/spec/template/spec/contaihers/98/image", "value";" 
gcr.io/google containers/nginx-slim:0.7"]]' 


# 删除 StatefulSet 和 Headless Service 
$ kubectl delete statefulset web 
$ kubectl delete service nginx 


# StatefulSet 删 除 后 PVC 还 会 保留 着 ， 数 据 不 再 使 用 的 话 也 需要 删除 
$ kubectl delete pvc www-web-0 www-web-1 


zookeeper 


另外 一 个 更 能 说 明 StatefulSet 强 大 功能 的 示例 为 zookeeperyaml， 这 个 例子 仅 为 讲 
解 ， 实 际 可 用 的 配置 请 使 用 
https://github.com/kubernetes/contrib/tree/master/statefulsets 中 的 配置 。 


apiVersion: vi 
kind: Service 


metadata: 
name: zk-headless 
labels: 
app: zk-headless 
spec: 
ports: 
- port: 2888 
name: server 
- port: 3888 


name: leader-election 
clusterIP: None 
selector: 
app: zk 
apiVersion: vi 
kind: ConfigMap 
metadata: 
name: zk-config 
data: 
ensemble: "zk-0;zk-1;zk-2" 


StatefulSet 


jvm.heap: "2G" 


tick: "2000" 
init: "10" 
sync: "5" 


client.cnxns: "60" 
snap.retain: "3" 
purge.interval: "1" 
apiVersion: policy/vibeta1 
kind: PodDisruptionBudget 
metadata: 
name: zk-budget 
spec: 
selector: 
matchLabels: 
app: zk 
minAvailable: 2 
apiVersion: apps/vibetai 
kind: StatefulSet 
metadata: 
name: zk 
spec: 
serviceName: zk-headless 
replicas: 3 
template: 
metadata: 
labels: 
app: zk 
annotations: 
pod.alpha.kubernetes.io/initialized: "true" 
scheduler.alpha.kubernetes.io/affinity: > 


"podAntiAffinity": { 
"requiredDuringSchedulingRequiredDuringExecution 


"labelSelector": ( 
"matchExpressions": [{ 
"key" í "app", 
"operator": "In", 
"yalues": ["zk-headless"] 


}] 
ty 


"topologyKey": "kubernetes.io/hostname" 


3] 
} 
} 
spec: 
containers: 
- Name: k8szk 
imagePullPolicy: Always 
image: gcr.io/google_samples/k8szk:v1 
resources: 


requests: 
memory: "4Gi" 
epui "3" 


ports: 


containerPort: 2181 
name: client 
containerPort: 2888 
name: server 
containerPort: 3888 
name: leader-election 


env: 


name : ZK ENSEMBLE 
valueFrom: 
configMapKeyRef: 
name: zk-config 
key: ensemble 
name : ZK HEAP SIZE 
valueFrom: 
configMapKeyRef: 
name: zk-config 
key: jvm.heap 
name : ZK TICK TIME 
valueFrom: 
configMapKeyRef: 
name: zk-config 
key: tick 
name : ZK INIT LIMIT 
valueFrom: 
configMapKeyRef: 
name: zk-config 
key: init 
name : ZK SYNC LIMIT 
valueFrom: 
configMapKeyRef: 
name: zk-config 
key: tick 
name : ZK MAX CLIENT CNXNS 
valueFrom: 
configMapKeyRef: 
name: zk-config 
key: client.cnxns 
name: ZK SNAP RETAIN COUNT 
valueFrom: 
configMapKeyRef: 
name: zk-config 
key: snap.retain 
name: ZK PURGE INTERVAL 
valueFrom: 
configMapKeyRef: 
name: zk-config 
key: purge.interval 
name: ZK CLIENT PORT 
value: "2181" 


- name: ZK_SERVER_PORT 
value: "2888" 
- name: ZK_ELECTION_PORT 
value: "3888" 
command: 
- sh 
- -C 
- zkGenConfig.sh && zkServer.sh start-foreground 
readinessProbe: 
exec: 
command: 

"ZkOk.sh" 
initialDelaySeconds: 15 
timeoutSeconds: 5 

livenessProbe: 
exec: 
command: 

"ZkOk.sh" 
initialDelaySeconds: 15 
timeoutSeconds: 5 

volumeMounts: 
- name: datadir 
mountPath: /var/lib/zookeeper 
securityContext: 
runAsUser: 1000 
fsGroup: 1000 
volumeClaimTemplates: 
- metadata: 
name: datadir 
annotations: 
volume.alpha.kubernetes.io/storage-class: anything 
spec: 
accessModes: [ "ReadWriteOnce" ] 
resources: 
requests: 
storage: 20Gi 


kubectl create -f zookeeper.yaml 


详细 的 使 用 说 明 见 zookeeper stateful application ° 


关于 StatefulSet 的 更 多 示例 请 参阅 github.com/kubernetes/contrib - statefulsets ， 
其 中 包括 了 zookeeper 和 kafka。 


集群 外 部 访问 StatefulSet 的 Pod 


我 们 设想 一 下 这 样 的 场景 : f£ kubernetes 4 4 ? 4 74 iX StatefulSet t 4j /$ 8 Pod ， 
那么 如 何 访问 这 些 的 pod 呢 ? 


方法 是 为 pod 设 置 label， 然 后 用 kubectl expose 将 其 以 NodePort 的 方式 暴露 到 
集群 外 部 ， 以 上 面 的 Zookeeper 的 例子 来 说 明 ， 下 面 使 用 命令 的 方式 来 暴露 其 中 的 
两 个 zookeeper 节 点 ， 也 可 以 写 一 个 serivce 配 置 yaml 文 件 。 

kubectl label pod zk-0 zkInst=0 

kubectl label pod zk-1 zkInst=1 


kubectl expose po zk-0 --port-2181 --target-port-2181 --name-zk- 
© --selector=zkInst=0 --type=NodePort 
kubectl expose po zk-1 --port=2181 --target-port-2181 --name-zk- 
1 --selector=zkInst=1 --type=NodePort 


这 样 在 kubernetes 集 群 外 部 就 可 以 根据 pod 所 在 的 主机 所 映射 的 端口 来 访问 了 。 


查看 zk-0 这 个 service 可 以 看 到 如 下 结果 : 


NAME CLUSTER- IP EXTERNAL - IP PORT(S) AGE 
zk-0 10.254.98.14 «nodes» 2181:31693/TCP 5m 


集群 外 部 就 可 以 使 用 所 有 的 node 中 的 任何 一 个 I|P:31693 来 访问 这 个 zookeeper 实 
例 o 


参考 


https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/ 
kubernetes contrib - statefulsets 


Copyright © jimmysong.io 2017-2018 all right reserved * powered by 
GitbookUpdated at 2018-05-09 14:15:47 


DaemonSet 


什么 是 DaemonSet ? 


DaemonSet 确保 全 部 (或 者 一 些 ) Node 上 运行 一 个 Pod 的 副本 。 当 有 Node 加 
入 集群 时 ， 也 会 为 他 们 新 增 一 个 Pod 。 当 有 Node 从 集群 移 除 时 ， 这 些 Pod 也 会 
被 回收 。 删 除 DaemonSet 将 会 删除 它 创建 的 所 有 Pod » 


使 用 DaemonSet 的 一 些 典型 用 法 : 


e 运行 集群 存储 daemon， 例 如 在 每 个 Node 上 运行 glusterd ^ ceph ° 
e 在 每 个 Node 上 运行 日 志 收 集 daemon， 例 如 fluentd ^ logstash ° 
e 在 每 个 Node 上 运行 监控 daemon， 例 如 Prometheus Node 

Exporter、 collectd 、Datadog 代理 、New Relic 代理 ， 或 Ganglia 


gmond ° 


一 个 简单 的 用 法 是 ， 在 所 有 的 Node 上 都 存在 一 个 DaemonSet， 将 被 作为 每 种 类 
型 的 daemon 使 用 。 一 个 稍微 复杂 的 用 法 可 能 是 ， 对 单独 的 每 种 类 型 的 daemon 
使 用 多 个 DaemonSet， 但 具有 不 同 的 标志 ， 和 /或 对 不 同 硬件 类 型 具有 不 同 的 内 
存 、CPU 要 求 。 


5 DaemonSet Spec 


Wy UE 


和 其 它 所 有 Kubernetes 配置 一 样 ，DaemonSet € € apiversion ^ kind 和 
metadata 字段 。 有 关 配 置 文件 的 通用 信息 ， 详 见 文档 部 署 应 用 、 配 置 容器 和 Wt 
源 管理 o 


DaemonSet 也 需要 一 个 ,spec 配置 段 。 


Pod 模板 


,Spec 唯一 必需 的 字段 是 .spec.template 。 


.spec.template 是 一 个 Pod 模板 。 €4 Pod 具有 相同 的 Schema， 除了 它 是 
REN > REAREA apiVersion 或 kind 字段 。 


Pod 除了 必须 字段 外 ， 在 DaemonSet 中 的 Pod 模板 必须 指定 合理 的 标签 (查看 
pod selector) 。 


在 DaemonSet 中 的 Pod 模板 必需 具有 一 个 值 为 Always 的 RestartPolicy ， 
或 者 未 指定 它 的 值 ， 默 认 是 Always ° 


Pod Selector 


.spec.selector 字段 表示 Pod Selector， 它 与 Job 或 其 它 资 源 的 
.sper.selector 的 原理 是 相同 的 。 


spec.selector 表示 一 个 对 象 ， 它 由 如 下 两 个 字段 组 成 : 


e matchLabels -与 ReplicationController 的 .spec.selector 的 原理 相 
同 。 

e matchExpressions -允许 构建 更 加 复杂 的 Selector， 可 以 通过 指定 Key ^ 
value 列表 ， 以 及 与 key 和 value 列表 的 相关 的 操作 符 。 


当 上 述 两 个 字段 都 指定 时 ， 结 果 表 示 的 是 AND 关系 。 


如 果 指 定 了 ,spec,selector * “#4 .spec.template.metadata. labels 
相 匹配 。 如 果 没 有 指定 ， 它 们 黑 认 是 等 价 的 。 如 果 与 它们 配置 的 不 匹配 ， 则 会 被 
API 拒绝 。 


如 果 Pod 的 label 与 selector 匹配 ， 或 者 直接 基于 其 它 的 DaemonSet、 或 者 
Controller (例如 ReplicationController) ， 也 不 可 以 创建 任何 Pod。 否则 
DaemonSet Controller 将 认为 那些 Pod 是 它 创 建 的 。Kubernetes 不 会 阻止 这 样 
做 。 一 个 场景 是 ， 可 能 希望 在 一 个 具有 不 同 值 的 、 用 来 测试 用 的 Node 上 手动 创建 
Pod ° 


仅 在 相同 的 Node 上 运行 Pod 


如 果 指 定 了 .spec.template.spec.nodeSelector ，DaemonSet Controller 将 
在 能 够 匹配 上 Node Selector 的 Node 上 创建 Pod。 类 似 这 种 情况 ， 可 以 指定 
.spec.template.spec.affinity ， 然 后 DaemonSet Controller 将 在 能 够 匹配 


Node Affinity 的 Node 上 创建 Pod » 如 果 根 本 就 没有 指定 ， 则 DaemonSet 
Controller 将 在 所 有 Node 上 创建 Pod 。 


如 何 调度 Daemon Pod 


正常 情况 下 ，Pod 运行 在 哪个 机 器 上 是 由 Kubernetes 调度 器 进行 选择 的 。 然 而 ， 
由 Daemon Controller 创建 的 Pod 已 经 确定 了 在 哪个 机 器 上 (Pod 创建 时 指定 了 


.spec.nodeName ) ， 因 此 : 


e DaemonSet Controller 并 不 关心 一 个 Node 的 unschedulable 字段 。 
e DaemonSet Controller 可 以 创建 Pod， 即 使 调度 器 还 没有 被 启动 ， 这 对 集群 局 
动 是 非常 有 帮助 的 。 


Daemon Pod 关心 Taint 和 Toleration， 它 们 会 为 没有 指定 tolerationSeconds 
的 node.alpha.kubernetes.io/notReady 和 
node.alpha.kubernetes.io/unreachable 的 Taint’ 而 创建 具有 NoExecute 
的 Toleration。 这 确保 了 当 alpha 特性 的 TaintBasedEvictions 被 启用 ， 当 
Node 出 现 故障 ， 上 比如 网 络 分 区 ， 这 时 它们 将 不 会 被 清除 掉 ( 当 
TaintBasedEvictions 特性 没有 启用 ， 在 这 些 场 景 下 也 不 会 被 清除 ， 但 会 因为 
NodeController 的 硬 编码 行为 而 被 清除 ，Toleration 是 不 会 的 ) 。 


与 Daemon Pod 通信 


5 DaemonSet 中 的 Pod 进行 通信 ， 几 种 可 能 的 模式 如 下 


e Push : 配置 DaemonSet 中 的 Pod 向 其 它 Service 发 送 更 新 ， 例 如 统计 数据 
库 。 它 们 没有 客户 端 。 

e NodelP 和 已 知 端口 : DaemonSet 中 的 Pod 可 以 使 用 hostPort ， 从 而 可 以 
通过 Node IP 访问 到 Pod。 客 户 端 能 通过 某 种 方法 知道 Node IP 列表 ， 并 且 基 
于 此 也 可 以 知道 端口 。 

e DNS: 创建 具有 相同 Pod Selector 的 Headless Service， 然 后 通过 使 用 

endpoints 资源 或 从 DNS 检索 到 多 个 入 记录 来 发 现 DaemonSet。 

e Service : 创建 具有 相同 Pod Selector 的 Service， 并 使 用 该 Service 访问 到 某 
个 随机 Node 上 的 daemon。 (没有 办 法 访问 到 特定 Node) 


更 新 DaemonSet 


如 果 修 改 了 Node Label > DaemonSet 将 立刻 向 新 匹配 上 的 Node 添加 Pod， 同 时 
删除 新 近 无 法 匹配 上 的 Node 上 的 Pod ° 


可 以 修改 DaemonSet 创建 的 Pod。 然 而 ， 不 允许 对 Pod 的 所 有 字段 进行 更 新 。 当 
下 次 Node (即使 具有 相同 的 名 称 ) 被 创建 时 ，DaemonSet Controller 还 会 使 用 最 
初 的 模板 。 


可 以 删除 一 个 DaemonSet。 如 果 使 用 kubectl 并 指定 --cascade=false 3& 
项 ， 则 Pod 将 被 保留 在 Node 上 。 BUE quA 同 模板 的 新 DaemonSet » 
具有 不 同 模板 的 新 DaemonSet 将 葵 能 够 通过 Label 匹配 识别 所 有 已 经 存在 的 
Pod。 它 不 会 修改 或 删除 它们 ， 即 使 是 错误 匹配 了 Pod 模板 。 通 过 删除 Pod 或 者 
删除 Node， 可 以 强制 创建 新 的 Pod » 


在 Kubernetes 1.6 或 以 后 版 本 ， 可 以 在 DaemonSet 上 执行 滚动 升级 。 


init 脚本 


很 可 能 通过 直接 在 一 个 Node 上 启动 daemon 进程 (例如 ， 使 用 
init ^ upstartd ^ X systemd ) 。 这 非常 好 ， 然 而 基于 DaemonSet 来 运 
行 这 些 进程 有 如 下 一 些 好 处 : 


e 像 对 待 应 用 程序 一 样 ， 具 备 为 daemon 提供 监控 和 管理 日 志 的 能 力 。 

e 为 daemon 和 应 用 程序 使 用 相同 的 配置 语言 和 工具 (如 Pod 模 
板 、 kubectl ) 。 

e Kubernetes 未 来 版 本 可 能 会 支持 对 DaemonSet 创建 Pod 与 Node 升 级 工作 流 
进行 集成 。 

e 在 资源 受 限 的 容器 中 运行 daemon， 能 够 增加 daemon 和 应 用 容器 的 隔离 性 。 
然而 这 也 实现 了 在 容器 中 运行 daemon， 但 却 不 能 在 Pod 中 运行 (例如 ， 直 接 
基于 Docker 启动 ) 。 


f Pod 


可 能 要 直接 创建 Pod， 同 时 指定 其 运行 在 特定 的 Node Eo 8t > DaemonSet 7$ 
换 了 由 于 任何 原因 被 删除 或 终止 的 Pod， 例 如 Node 失败 、 例 行 节点 维护 ， 比 如 内 
核 升级 。 由 于 这 个 原因 ， 我 们 应 该 使 用 DaemonSet 而 不 是 单独 创建 Pod 。 


$$ 4& Pod 


很 可 能 ， 通 过 在 一 个 指定 目录 下 编写 文件 来 创建 Pod， 该 目录 受 Kubelet 所 监视 。 
X Pod 被 称 为 静态 Pode 不 像 DaemonSet > 4$ A Pod 不 受 kubect| 和 HE 
Kubernetes API Z P 35 /& 3€ » $$ A Pod 不 依赖 于 apiserver， 这 使 得 它们 在 集群 局 

动 的 情况 下 非常 有 用 。 mE’ RRA Pod 可 能 会 被 废弃 掉 。 


Replication Controller 


DaemonSet 4 ine Controller 非常 类 似 ， 它 们 都 能 创建 Pod » 2k Pod 都 
具有 不 期 望 被 终止 的 进程 (例如 ，Web 服务 器 、 存 储 服务 器 ) 。 为 无 状态 的 
Service 使 用 ee Controller， 像 ffontend， 实 现 对 副本 的 数量 进行 扩 缩 容 、 
平滑 升级 ， 比 之 于 精确 控制 Pod ee 。 需 要 Pod 副本 总 

是 运行 在 全 部 或 特定 主机 上 ， 并 需要 先 于 其 他 Pod 启动 ， 当 这 被 认为 非常 重要 时 ， 
应 该 使 用 Daemon Controller ° 
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ReplicationController?e ReplicaSet 


ReplicationCtronller 用 来 确保 容器 应 用 的 副本 数 始 终 保 持 在 用 户 定 义 的 副本 数 ， 即 
如 果 有 容器 异常 退出 ， 会 自动 创建 新 的 Pod 来 替代 ; 而 如 果 异 常 多 出 来 的 容器 也 会 
自动 回收 。 


在 新 版 本 的 Kubernetes 中 建议 使 用 ReplicaSet 来 取代 ReplicationCtronller。 
ReplicaSet 跟 ReplicationCtronller 没 有 本 质 的 不 同 ， 只 是 名 字 不 一 样 ， 并 且 
ReplicaSet 支 持 集合 式 的 selector 。 


虽然 ReplicaSet 可 以 独立 使 用 ， 但 一 般 还 是 建议 使 用 Deployment 来 自动 管理 
ReplicaSet， 这 样 就 无 需 担 心 跟 其 他 机 制 的 不 兼容 问题 (比如 ReplicaSet 不 支持 
rolling-update 但 Deployment 支 持 ) ° 


ReplicaSet 示 例 : 


ReplicationControllerfe ReplicaSet 


apiVersion: extensions/vibeta1 
kind: ReplicaSet 
metadata: 
name: frontend 
# these labels can be applied automatically 
# from the labels in the pod template if not set 
# labels: 
# app: guestbook 
# tier: frontend 
spec: 
# this replicas value is default 
# modify it according to your case 
replicas: 3 
# selector can be applied automatically 
# from the labels in the pod template if not set, 
# but we are specifying the selector here to 
# demonstrate its usage. 


selector: 
matchLabels: 
tier: frontend 
matchExpressions: 
- {key: tier, operator: In, values: [frontend]} 
template: 
metadata: 
labels: 


app: guestbook 
tier: frontend 
spec: 
containers: 
- name: php-redis 
image: gcr.io/google_samples/gb- frontend: v3 


resources: 
requests: 
cpu: 100m 
memory: 100Mi 
env: 


- name: GET_HOSTS_FROM 
value: dns 
# If your cluster config does not include a dns servic 
e, then to 
# instead access environment variables to find service 
host 
# info, comment out the 'value: dns' line above, and u 
ncomment the 
# line below. 
# value: env 
ports: 
- containerPort: 80 


Copyright © jimmysong.io 2017-2018 all right reserved > powered by 


251 


GitbookUpdated at 2018-05-09 14:15:47 


Job 


Job 负 责 批 处 理 任 务 ， 即 仅 执 行 一 次 的 任务 ， 它 保证 批 处 理 任 务 的 一 个 或 多 个 Pod 成 
功 结 


Job Spec 格 式 


e spec.template 格 式 同 Pod 

e RestartPolicy 仅 支持 Never 或 OnFailure 

e 单个 Pod 时 ， 上 默认 Pod 成 功 运 行 后 Job 即 结 

e .spec.completions 标志 Job 结 束 需 要 成 功 运行 的 Pod 个 数 ， 默 认为 1 

e .spec.parallelism 标志 并 行 运行 的 Pod 的 个 数 ， 默 认为 1 

e spec.activeDeadlineSeconds 标志 失败 Pod 的 重 试 最 大 时 间 ， 超 过 这 个 时 
间 不 会 继续 重 试 


一 个 简单 的 例子 : 


apiVersion: batch/v1 
kind: Job 
metadata: 
name: pi 
spec: 
template: 
metadata: 
name: pi 
spec: 
containers: 
- name: pi 
image: perl 
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(20 
00)"] 
restartPolicy: Never 


$ kubectl create -f ./job.yaml 

job "pi" created 

$ pods=$(kubectl get pods --selector=job-name=pi --output=jsonpa 
th={.items..metadata.name}) 

$ kubectl logs $pods 

3.141592653589793238462643383279502... 


Bare Pods 


Pt i8 Bare Pods 是 指 直接 用 PodSpec 来 创建 的 Pod ( 即 不 在 ReplicaSets 或 者 
ReplicationController 的 管理 之 下 的 Pods) 。 这 些 Pod 在 Node 重 启 后 不 会 自动 重 
局， 但 Job 则 会 创建 新 的 Pod 继 续 任 务 。 所 以 ， 推 荐 使 用 Job 来 替代 Bare Pods > Pp 
便 是 应 用 只 需要 一 个 Pod 。 
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CronJob 


Cron Job 管理 基于 时 间 的 Job， 即 : 


e 在 给 定时 间 点 只 运行 一 
。 周 期 性 地 在 给 定时 间 点 运行 


一 个 CronJob 对 象 类 似 于 crontab (cron table) 文件 中 的 一 行 。 它 根据 指定 的 预 
定 计划 周期 性 地 运行 一 个 Job， 格 式 可 以 参考 Cron 。 


前 提 条 件 


当 使 用 的 Kubernetes 集群 ， 版 本 >= 1.4 (对 ScheduledJob) ，>= 1.5 (对 
Prae ， 当 启动 API Server (参考 为 集群 开启 或 关闭 API 版 本 获取 更 多 信 
A) 时 ， 通 过 传递 选项 --runtime-config-batch/v2alphai-true 可 以 开启 
a eae API ° 


典型 的 用 法 如 下 所 示 : 


e 在 给 定 的 时 间 点 调度 Job 运行 
创建 周期 性 运行 的 Job， 例 如 : 数据 库 备份 、 发 送 邮 件 。 


CronJob Spec 


e .spec.schedule : 调度 ， 必 需 字 段 ， 指 定 任务 运行 周期 ， 格 式 同 Cron 


e .spec.jobTemplate : Job 模板 ， 必 需 字段 ， 指 定 需 要 运行 的 任务 ， 格 式 同 
Job 
e .spec.startingDeadlineSeconds :启动 Job 的 期 限 Mni ， 该 字段 
是 可 选 的 。 如 果 因 为 任何 原因 而 错过 了 被 调度 的 时 间 ， 那 么 错过 执行 时 间 的 
Job 将 被 认为 是 失败 的 。 如 果 没有 指定 ， 则 没有 期 限 
e .spec.concurrencyPolicy : 并 发 策略 ， 该 字段 也 是 可 选 的 。 它 指定 了 如 何 
处 理 被 Cron Job 创建 的 Job 的 并 发 执行 。 只 允许 指定 下 面 策略 中 的 一 种 : 
o Allow (RU) : 允许 并 发 运行 Job 
o Forbid : 禁止 并 发 运行 ， 如 果 前 一 个 还 没有 完成 ， 则 直接 跳 过 下 一 个 


o Replace : 取消 当前 正在 运行 的 Job， 用 一 个 新 的 来 替换 
注意 ， 当 前 策略 只 能 应 用 于 同一 个 Cron Job 创建 的 Job。 如 果 存 在 多 个 Cron 
Job， 它 们 创建 的 Job 之 间 总 是 允许 并 发 运行 。 


e .spec.suspend : 挂 起 ， 该 字段 也 是 可 选 的 。 如 果 设 置 为 true ， 后 续 所 
有 执行 都 会 被 挂 起 。 它 对 已 经 开始 执行 的 Job BÆR o REH false 。 


e .spec.successfulJobsHistoryLimit 和 
.spec.failedJobsHistoryLimit :历史 限制 ， 是 可 选 的 字段 。 它 们 指定 了 
可 以 保留 多 少 完成 和 失败 的 Job。 


默认 没有 限制 ， 所 有 成 功 和 失败 的 Job 都 会 被 保留 。 然 而 ， 当 运行 一 个 Cron 


Job 时 ，Job 可 以 很 快 就 堆积 很 多 ， 推 荐 设置 这 两 个 字段 的 值 。 设 置 限制 的 值 
A 0 ， 相 关 类 型 的 Job 完成 后 将 不 会 被 保留 。 


apiVersion: batch/v2alpha1 
kind: CronJob 
metadata: 
name: hello 
spec: 
schedule: "*/3 * * * =" 
jobTemplate: 
spec: 
template: 
spec: 
containers: 
- name: hello 
image: busybox 
args: 
- /bin/sh 
- -C 
- date; echo Hello from the Kubernetes cluster 
restartPolicy: OnFailure 


$ kubectl create -f cronjob.yaml 
cronjob "hello" created 


当然 ， 也 可 以 用 kubectl run 来 创建 一 个 CronJob : 


kubectl run hello --schedule="*/i * * * *" --restart-OnFailure - 
-image-busybox -- /bin/sh -c "date; echo Hello from the Kubernet 


es cluster" 


$ kubectl get cronjob 


NAME SCHEDULE SUSPEND ACTIVE LAST - SCHEDULE 
hello uq ese False 0 <none> 

$ kubectl get jobs 

NAME DESIRED SUCCESSFUL AGE 
hello-1202039034 1 1 49s 


$ pods=$(kubectl get pods --selector=job-name=hello-1202039034 - 
-output=jsonpath={.items..metadata.name} -a) 

$ kubectl logs $pods 

Mon Aug 29 21:34:09 UTC 2016 

Hello from the Kubernetes cluster 


" 
iF 


注意 ， 删 除 cronjob 的 时 候 不 会 自动 删除 job， 这 些 job 可 以 用 kubectl1 delete j 
0 来 删除 

$ kubectl delete cronjob hello 

cronjob "hello" deleted 


Cron Job 限制 


Cron Job 在 每 次 调度 运行 时 间 内 AR 会 创建 一 个 Job 对 象 。 我 们 之 所 以 说 AB 
> ee 会 创建 两 个 Job， 或 者 一 个 Job 都 没 创建 。 我 们 尝试 
少 发 生 这 种 情况 ， 但 却 不 能 完全 避免 。 因 此 ， 创 建 Job 操作 应 该 是 REM o 


Job 根据 它 所 创建 的 Pod 的 并 行 度 ， 负 责 重 试 创 建 Pod， 并 就 决定 这 一 组 Pod 的 
成 功 或 失败 。Cron Job 根本 就 不 会 去 检查 Pod 。 


删除 Cron Job 
一 旦 不 再 需要 Cron Job， 简 单 地 可 以 使 用 kubectl 命令 删除 它 


$ kubectl delete cronjob hello 
cronjob "hello" deleted 


将 会 终止 正在 创建 的 Job。 然 而 ， 运 行 中 的 Job 将 不 会 被 终止 ， 不 会 删除 Job 或 
14) Pod 。 为 了 清理 那些 Job 和 Pod， 需 要 列 出 该 Cron Job 创建 的 全 部 Job ， 


$ kubectl get jobs 


NAME DESIRED SUCCESSFUL AGE 
hello-1201907962 1 1 11m 
hello-1202039034 1 1 am 


$ kubectl delete jobs hello-1201907962 hello-1202039034 ... 
job "hello-1201907962" deleted 
job "hello-1202039034" deleted 


一 旦 Job 被 删除 ， 由 Job 创建 的 Pod 也 会 被 删除 。 注 意 ， 所 有 由 名 称 为 “hello” 的 
Cron Job 创建 的 Job 会 以 前 级 字符 囊 “hello-” 进行 命名 。 如 果 想 要 删除 当前 
Namespace 中 的 所 有 Job， 可 以 通过 命令 kubectl delete jobs --all 立刻 
删除 它们 。 
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Horizontal Pod Autoscaling 


z. F] 84) 35 28.485 FE] 3 38 ABA RE FOR AG PAR > dep HESS > Ge ey BE AY EA E 
源 利 用 率 ， 让 Service 中 的 Pod 个 数 自动 调整 呢 ? 3x HA MT Horizontal Pod 
Autoscaling f * MÆ E 3L > 4&PodzK- TF B 3 2à 3X » ix 4 Object (KPod ` 
Deployment— 4f 4f API resource) 也 是 最 能 体现 kubernetes 之 于 传统 运 维 价值 的 
地 方 ， 不 再 需要 手动 扩容 了 ， 终 于 实现 自动 化 了 ， 还 可 以 自 定义 指标 ， 没 准 未 来 还 
可 以 通过 人 工 智 能 自动 进化 呢 | 


HPA 属 于 Kubernetes 中 的 autoscaling SIG (Special Interest Group) ， 其 下 有 两 
个 feature : 


e Arbitrary/Custom Metrics in the Horizontal Pod Autoscaler#117 
e Monitoring Pipeline Metrics HPA API #118 


Kubernetes 自 1.2 版 本 引入 HPA 机 制 ， 到 1.6 版 本 之 前 一 直 是 通过 kubelet 来 获取 监控 
指标 来 判断 是 否 需 要 扩 缩 容 ，1.6 版 本 之 后 必须 通过 APlI server、Heapseter 或 者 
kube-aggregator 来 获取 监控 指标 。 


对 于 1.6 以 前 版 本 中 开启 自 定义 HPA 请 参考 Kubernetes autoscaling based on 
custom metrics without using a host port， 对 于 1.7 及 以 上 版 本 请 参考 Configure 
Kubernetes Autoscaling With Custom Metrics in Kubernetes 1.7 - Bitnami ° 


HPA f£ 9t 


Horizontal Pod Autoscaling 4x ié J] T Deployment £e ReplicationController » 4 V17& 
本 中 仅 支 持 根据 Pod 的 CPU 利用 率 扩 所 容 ， 在 v1alpha 版 本 中 ， 支 持 根据 内 存 和 用 户 
自 定 义 的 metric 扩 缩 容 。 


如 果 你 不 想 看 下 面 的 文章 可 以 直接 看 下 面 的 示例 图 ， 组 件 交互 、 组 件 的 配置 、 命 令 
示例 ， 都 画 在 图 上 了 。 


Horizontal Pod Autoscaling & API server 和 controller 共 同 实现 。 


， Create new pods Pod N 


















* Pod 1 EE. "ow Re 
Get resource metrics 
CPU(v1) 
Memory(v2alpha1) RC/ Deployment 


Custom metrics(v2alpha1) 





kubectl autoscale deployment foo 
--min=2 --max=5 --cpu-percent=80 






Resource Metrics API 


API Server 


--horizontal-pod-autoscaler-use-rest-clients=true 
--api-server=${API server aggregator} 


Controller Manager 


Source https://github.com/rootsongjc/kubernetes-handbook 


图 片 - horizontal-pod-autoscaler 


Metrics 支 持 


在 不 同 版 本 的 API 中 ，HPA autoscale 时 可 以 根据 以 下 指标 来 判断 : 


e autoscaling/v1 
o CPU 
e autoscaling/v2alpha1 
o 内 存 
o 自 定 义 metrics 
= kubernetes1.6 起 支持 自 定义 metrics， 但 是 必须 在 kube-controller- 
manager 中 配置 如 下 两 项 : 
m --horizontal-pod-autoscaler-use-rest-clients-true 
m --api-server 指向 kube-aggregator， 也 可 以 使 用 heapster 来 
实现 ， 通 过 在 启动 heapster 的 时 候 指定 --api-server=true 。 
查看 kubernetes metrics 
o 多 种 metrics 组 合 
a HPA 会 根据 每 个 metric 的 值 计 算出 scale 的 值 ， 并 将 最 大 的 那个 指 作为 
扩容 的 最 终结 果 。 


1& A kubectl © 3€ 


Horizontal Pod Autoscaling*# 4 API resource% "T Z4 4 Pod ` Deployment— -4£ Jf] 
kubeclt 命 令 管理 ， 使 用 方法 跟 它 们 一 样 ， 资 源 名 称 为 hpa » 


kubectl create hpa 
kubectl get hpa 
kubectl describe hpa 
kubectl delete hpa 


有 一 点 不 同 的 是 ， 可 以 直接 使 用 kubectl autoscale 直接 通过 命令 行 的 方式 创建 
Horizontal Pod Autoscaler ° 


用 法 如 下 : 


kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min-M 
INPODS] --max=MAXPODS 
[--cpu-percent=CPU] [flags] [options] 


举 个 例子 : 


kubectl autoscale deployment foo --min=2 --max=5 --cpu-percent=8 
0 


A Deployment foo 创 建 一 个 autoscaler， 当 Pod 的 CPU 利用 率 达 到 80% 的 时 候 ，RC 
的 replica 数 在 2 到 5 之 间 。 该 命令 的 详细 使 用 文档 见 https://kubernetes.io/docs/user- 
guide/kubectl/v1.6/#autoscale 。 


注意 : 如 果 为 ReplicationController 创 建 HPA 的 话 ， 无 法 使 用 rolling update， 但 是 
对 于 Deployment 来 说 是 可 以 的 ， 因 为 Deployment 在 执行 rolling update 的 时 候 会 自 
动 创建 新 的 ReplicationController ° 


什么 是 Horizontal Pod Autoscaling ? 


利用 Horizontal Pod Autoscaling > kubernetes 能 够 根据 监测 到 的 CPU HAF (或 
者 在 alpha 版 本 中 支持 的 应 用 提供 的 metric) 自动 的 扩容 replication controller > 
deployment 和 replica set ° 


Horizontal Pod Autoscaler 作为 kubernetes API resource 和 controller 的 实现 。 
Resource #4 x controller 424773 ° Controller 会 根据 监测 到 用 户 指 定 的 目标 的 CPU 
利用 率 周 期 性 得 调整 replication controller 或 deployment 的 replica 数量 。 


Horizontal Pod Autoscaler 如 何 工 作 ? 


Horizontal Pod Autoscaler 由 一 个 控制 循环 实现 ， 循 环 周期 由 controller manager 
中 的 --horizontal-pod-autoscaler-sync-period 标志 指定 (默认 是 30 
47) 。 


在 每 个 周期 内 ，controller manager 会 查询 HorizontalPodAutoscaler 中 定义 的 
metric 4&4 wF] A 48 » Controller manager 从 resource metric API (每 个 pod 的 
resource metric) 或 者 自 定 义 metric API (所 有 的 metric) 中 获取 metric » 


e 每 个 Pod 的 resource metric (例如 CPU) ，controller 通过 resource metric 
API 获取 HorizontalPodAutoscaler 中 定义 的 每 个 Pod 中 的 metric。 然后， 如 
RAAT ARAA Z > controller 计算 利用 的 值 与 每 个 Pod 的 容器 里 的 
resource request 值 的 百分比 。 如 果 设 置 了 目标 原始 值 ， 将 直接 使 用 该 原始 
metric 值 。 然 后 controller 计算 所 有 目标 Pod 的 利用 率 或 原始 值 (取决 于 所 指 
定 的 目标 类 型 ) 的 平均 值 ， 产生 一 个 用 于 缩放 所 需 replica 数量 的 比率 。 请 注 
意 ， 如 果 某 些 Pod 的 容器 没有 设置 相关 的 resource request ， 则 不 会 定义 
Pod 的 CPU 利用 率 ， 并 且 Aucoscaler 也 不 会 对 该 metric 采取 任何 操作 。 有 
关 自 动 缩放 算法 如 何 工作 的 更 多 细节 ， 请 参阅 自动 缩放 算法 设计 文档 。 

e 对 于 每 个 Pod 自 定义 的 metric > controller 功能 类 似 于 每 个 Pod 的 resource 
metric， 只 是 它 使 用 原始 值 而 不 是 利用 率 值 。 

e 对 于 object metric， 获 取 单 个 度量 (描述 有 问题 的 对 象 ) ， 并 与 目标 值 进 行 比 
较 ， 以 产生 如 上 所 述 的 比率 。 


HorizontalPodAutoscaler 控制 器 可 以 以 两 种 不 同 的 方式 获取 metric : 直接 的 
Heapster 访问 和 REST 客户 端 访问 。 


当 使 用 直接 的 Heapster 访问 时 ，HorizontalPodAutoscaler 直接 通过 API 服务 器 的 
服务 代理 子 资源 查询 Heapster。 需 要 在 集群 上 部 署 Heapster 并 在 kube-system 
namespace 中 运行 。 


有 关 REST 客户 端 访 问 的 详细 信息 ， 请 参阅 支持 自 定义 度量 。 


Autoscaler 访问 相应 的 replication controller > deployment 或 replica set 来 缩放 子 


Scale 是 一 个 允许 您 动态 设置 副本 数 并 检查 其 当前 状态 的 接口 。 


有 关 缩 放 子 资源 的 更 多 细节 可 以 在 这 里 找到 。 


API Object 


Horizontal Pod Autoscaler Æ kubernetes 的 autoscaling API 组 中 的 API it 
源 。 当 前 的 稳定 版 本 中 ， 只 支持 CPU 自动 扩 缩 容 ， 可 以 在 autoscaling/vi API 
版 本 中 找到 。 


在 alpha 版 本 中 支持 根据 内 存 和 自 定义 metric 扩 缩 容 ， 可 以 
在 autoscaling/v2alphai 中 找到 。 autoscaling/v2alphai 中 引入 的 新 字段 
在 autoscaling/vi 中 是 做 为 annotation 而 保存 的 。 


关于 该 API 对 象 的 更 多 信息 ， 请 参阅 HorizontalPodAutoscaler Object 。 


在 kubectl 中 支持 Horizontal Pod Autoscaling 


Horizontal Pod Autoscaler 和 其 他 的 所 有 API 资源 一 样 ， 通 过 kubect1 以 标准 的 
方式 支持 。 


我 们 可 以 使 用 kubectl create 命令 创建 一 个 新 的 autoscaler ° 


我 们 可 以 使 用 kubectl get hpa 列 出 所 有 的 autoscaler， 使 用 kubect1 
describe hpa 获取 其 详细 信息 。 


最 后 我 们 可 以 使 用 kubect1 delete hpa 删除 autoscaler。 


另外 ， 可 以 使 用 kubectl autoscale 命令 ， 很 轻易 的 就 可 以 创建 一 个 Horizontal 
Pod Autoscaler ° 


例如 ， 执 行 kubectl autoscale rc foo -min=2 -max=5 —cpu-percent=80 命 
令 将 为 replication controller foo 创建 一 个 autoscaler， 目 标的 CPU 4#] 7 XE 
是 80% ，replica 的 数量 介 于 2 和 5 之 间 。 


关于 kubectl autoscale 的 更 多 信息 请 参阅 这 里 。 


滚动 更 新 期 间 的 自动 扩 缩 容 


目前 在 Kubernetes 中 ， 可 以 通过 直接 管理 replication controller 或 使 用 deployment 
对 象 来 执行 滚动 更 新 ， 该 mod 对 象 为 您 管理 基础 replication controller ° 


Horizontal Pod Autoscaler 仅 支持 后 一 种 方法 : Horizontal Pod Autoscaler 被 绑 定 
到 deployment 对 象 ， 它 设置 deployment 对 象 的 大 小 ，deployment 负责 设置 底层 
replication controller 的 大 小 。 


Horizontal Pod Autoscaler 不 能 使 用 直接 操作 replication controller 进行 滚动 更 新 ， 
即 不 能 将 Horizontal Pod Autoscaler 绑 定 到 replication controller， 并 进行 滚动 更 新 
(例如 使 用 kubectl rolling-update ) ° 


这 不 行 的 原因 是 ， 当 滚动 更 新 创建 一 个 新 的 replication controller 时 ，Horizontal 
Pod Autoscaler 将 不 会 绑 定 到 新 的 replication controller 上 。 


支持 多 个 metric 


Kubernetes 1.6 中 增加 了 支持 基于 多 个 metric 的 扩 缩 容 。 您 可 以 使 

用 autoscaling/v2alphai API 版 本 来 为 Horizontal Pod Autoscaler 指定 多 个 
metric。 然 后 Horizontal Pod Autoscaler controller 将 权衡 每 一 个 metric， 并 根据 该 
metric 提议 一 个 新 的 scale。 在 所 有 提议 里 最 大 的 那个 scale 将 作为 最 终 的 scale 。 


支持 自 定 义 metric 


注意 : Kubernetes 1.2 根据 特定 于 应 用 程序 的 metric ， 通 过 使 用 特殊 注释 的 方 
式 ， 增 加 了 对 缩放 的 alpha 支持 。 


在 Kubernetes 1.6 中 删除 了 对 这 些 注释 的 支持 ， 有 利于 Suus litat joe 
API» 虽然 日 的 收集 自 定 义 metric 的 昌 方 法 仍然 可 用 ， 但 是 这 些 metric 将 不 可 供 
Horizontal Pod Autoscaler 使 用 ， 并 且 用 于 指定 要 缩放 的 自 定 义 metric 的 以 前 的 注 
释 也 不 在 受 Horizontal Pod Autoscaler 认可 。 


Kubernetes 1.6 增 加 了 在 Horizontal Pod Autoscale r 中 使 用 自 定义 metric 的 支持 。 


您 可 以 为 autoscaling/v2alphai API 中 使 用 的 Horizontal Pod Autoscaler 添加 
自 定义 metric ° 


Kubernetes 然后 查询 新 的 自 定 义 metric API 来 获取 相应 自 定 义 metric 4 1A » 


前 提 条 件 


为 了 在 Horizontal Pod Autoscaler 中 使 用 自 定义 metric， 您 必须 在 您 集群 的 
controller manager 中 将 --horizontal-pod-autoscaler-use-rest-clients 
标志 设置 为 trtue。 然 后 ， 您 必须 通过 将 controller manager 的 目标 API server 设置 
A API server aggregator (使 用 --apiserver 标志 ) ， 配 置 您 的 controller 
manager 通过 API server aggregator 与 API server 通信 。 Resource metric API 和 
É SL metric API 也 必须 向 API server aggregator 注册 ， 并 且 必 须 由 集群 上 运行 
的 API server 提供 。 


您 可 以 使 用 Heapster 实现 resource metric API， 方 法 是 将 --api-server 标志 
设置 为 true 并 运行 Heapster。 单独 的 组 件 必 须 提供 自 定义 metric API (有 关 自 定 
义 metric API 的 更 多 信息 ， 可 从 k8s.io/metrics repository 获得 ) 。 


进一步 阅读 


e 设计 文档 : Horizontal Pod Autoscaling 
e kubectl autoscale 命令 : kubectl autoscale 
e 使 用 例子 : Horizontal Pod Autoscaler 


HPAd& X 
74 : https://github.com/kubernetes/community/blob/master/contributors/design- 
proposals/horizontal-pod-autoscaler.md 


HPA 说 明 : https://kubernetes.io/docs/tasks/run-application/horizontal-pod- 
autoscale/ 


HPA 详 解 : https://kubernetes.io/docs/tasks/run-application/horizontal-pod- 
autoscale-walkthrough/ 


kubectl autoscale 命 令 详 细 使 用 说 明 : https://kubernetes.io/docs/user- 
guide/kubectl/v1.6/#autoscale 


自 定义 metrics 开 发 : https://github.com/kubernetes/metrics 


1.7 版 本 的 kubernetes 中 局 用 自 定义 HPA : Configure Kubernetes Autoscaling With 
Custom Metrics in Kubernetes 1.7 - Bitnami 


Copyright © jimmysong.io 2017-2018 all right reserved > powered by 
GitbookUpdated at 2018-05-09 14:15:47 


日 定义 指标 HPA 
Kubernetes 中 不 仅 支持 CPU、 内 存 为 指标 的 HPA， 还 支持 自 定义 指标 的 HPA， 例 如 
QPS ° 


本 文中 使 用 的 yaml 文 件 见 manifests/HPA 。 


设置 自 定 义 指 标 
kubernetes1.6 

在 kubernetes1.6 集 群 中 配置 自 定义 指标 的 HPA 的 说 明 已 废弃 。 
在 设置 定义 指标 HPA 之 前 需要 先进 行 如 下 配置 

e 将 heapster 的 启动 参数 --api-server 设置 为 true 


启用 custom metric API 

e don controller-manager 的 启动 参数 中 --horizontal-pod-autoscaler- 
use-rest-clients 设置 为 true， 并 指定 --master AAPI server 地 址 ， 如 -- 
master=http://172.20.0.113:8080 


在 kubernetes1.5 以 前 很 容易 设置 ， 参 考 1.6 以 前 版 本 的 kubernetes 中 开启 自 定义 
HPA ， 而 在 1.6 中 因为 取消 了 原来 的 annotation 方 式 设置 custom metric， 只 能 通过 
API server 和 kube-aggregator 来 获取 custom metric， 因 为 只 有 两 种 方式 来 设置 了 ， 
一 是 直接 通过 APlI server 获 取 heapster 的 metrics， 二 是 部 署 kube-aggragator 来 实 
3 o 


e. 


我 们 将 在 kubernetes1.8 版 本 的 kubernetes 中 ， 使 用 聚合 的 API server 来 实现 自 定义 
指标 的 HPA。 


kuberentes1.7+ 
确认 您 的 kubernetes 版 本 在 1.7 或 以 上 ， 修 改 以 下 配置 


e 将 kube-controller-manager 的 启动 参数 中 --horizontal-pod-autoscaler- 
use-rest-clients 设置 为 true， 并 指定 --master AAPI server 地 址 ， 如 `-- 
master=http://172.20.0.113:8080 

e 修改 kube-apiserver 的 配置 文件 apiserver， 增 加 一 条 配置 --requestheader - 


client-ca-file=/etc/kubernetes/ssl/ca.pem --requestheader - 
allowed-names-aggregator --requestheader-extra-headers-prefix-X- 
Remote-Extra- --requestheader -group-headers=X-Remote-Group -- 
requestheader -username-headers=X-Remote-User --proxy-client- 
cert-file=/etc/kubernetes/ssl/kubernetes.pem --proxy-client-key- 
file-/etc/kubernetes/ssl/kubernetes-key.pem ， 用 来 配置 aggregator 的 
CATE 4 ° 


已 经 内 置 了 apiregistration.k8s.io/vibetai API， 可 以 直接 定义 
APIService * + : 


apiVersion: apiregistration.k8s.io/vi 
kind: APIService 
metadata: 
name: vi.custom-metrics.metrics.k8s.io 
spec: 
insecureSkipTLSVerify: true 
group: custom-metrics.metrics.k8s.io 
groupPriorityMinimum: 1000 
versionPriority: 5 
service: 
name: api 
namespace: custom-metrics 
version: vi1alpha1i 


3 Prometheus 
1& f] prometheus-operator.yaml xX fF3$ Prometheus operator ° 
注意 : 将 镜像 修改 为 你 自己 的 镜像 仓库 地 址 。 


这 产生 一 个 自 定 义 的 API : http://172.20.0.113:8080/apis/custom- 
metrics.metrics.k8s.io/v1alpha1， 可 以 通过 浏览 器 访问 ， 还 可 以 使 用 下 面 的 命令 可 
以 检查 该 API : 


自 定义 指标 HPA 


$ kubectl get --raw-apis/custom-metrics.metrics.k8s.io/vialphai 
("kind":"APIResourceList", 'apiVersion":"v1","groupVersion":"cust 
om-metrics.metrics.k8s.io/vialphai", "resources":[{"name":"jobs.b 
atch/http requests", "SingularName":"", "namespaced": true, "kind":" 
MetricValueList", "verbs": ["get"]}, ("name":"namespaces/http reque 
sts", "singularName":"", "namespaced": false, "kind": "MetricValueLis 
t", "verbs": ["get"]}, ("name":"jobs.batch/up", "singularName":"","n 
amespaced": true, "kind": "MetricValueList", "verbs": ["get"]}, ("name" 
:"pods/up", " singularName":"", "namespaced": true, "kind": "MetricVal 
ueList", "verbs": ["get"]},{"name":"services/scrape_samples_ scrape 
d","singularName":"", "namespaced": true, "kind": "MetricValueList", 
"verbs": ["get"]}, ("name":"namespaces/scrape samples scraped","si 
ngularName":"", "namespaced": false, 'kind":"MetricValueList", "verb 
s":["get"]}, ("name":"pods/scrape duration seconds"," "singularName" 
;"", namespaced":true, "kind":"MetricValueList","verbs":["get"]), { 
"name":"services/scrape duration seconds"," 'singularName":"","nam 
espaced": true, "kind":"MetricValueList"," verbs": ["get"]) , ("name": 
"pods/http requests", "singularName":"","namespaced" :true, "kind": 
"MetricValueList", verbs":["get"]), ("name":"pods/scrape samples 
post metric relabeling","singularName":"","namespaced":true, "kin 
d":"MetricValueList", 'verbs":["get"]?, ("name":"jobs.batch/scrape 
samples scraped"," "singularName":"", "namespaced": true, "kind":"Me 
tricValuelist","verbs":["get"]3, ("name":"jobs.batch/scrape durat 
ion seconds","'singularName":"","namespaced":true, "kind":"MetricV 
alueList","verbs":["get"]}, ("name":"namespaces/scrape duration s 
econds", "singularName":"", "namespaced": false, 'kind":"MetricValue 
List","verbs":["get"]3, ("name":"namespaces/scrape samples post m 
etric relabeling","singularName":"","namespaced":false, "kind":"M 
etricValueList","verbs":["get"]), ("name":"services/scrape sample 
s post metric relabeling"," "singularName":"", "namespaced": true, "k 
ind": "MetricValueList", "verbs": ["get"]}, ("name":"services/up","s 
ingularName":"", "namespaced": true, "kind":"MetricValueList", "verb 
s":[E"get"]}, ("name":"pods/scrape samples scraped","singularName": 
"","namespaced":true, "kind": "MetricValueList", "verbs": ["get"]}, { 
"name": ""sServices/http_requests", "SingularName":"", "namespaced":t 
rue, "kind": "MetricValueList", "verbs": ["get"]}, ("name":"jobs.batc 
h/scrape samples post metric relabeling","singularName":"","name 
spaced" :true, "kind": "MetricValueList", "verbs": ["get"]},{"name":" 
namespaces/up", "SingularName":"", "namespaced": false, "kind": "Metr 
icValueList", "verbs": ["get"]}]} 


n ——Á—MÀes | 


1.6 以 前 版 本 的 kubernetes 中 开局 自 定 义 HPA 
1.7 版 本 的 kubernetes 中 启用 自 定 义 HPA 


Horizontal Pod Autoscaler Walkthrough 
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Copyright © jimmysong.io 2017-2018 all right reserved > powered by 
GitbookUpdated at 2018-05-09 14:15:47 


服务 发 现 
Kubernetes 中 为 了 实现 服务 实例 间 的 负载 均衡 和 不 同 服务 间 的 服务 发 现 ， 创 造 了 
Serivce 对 象 ， 同 时 又 为 从 集群 外 部 访问 集群 创建 了 Ingress 对 象 。 
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Service 


Kubernetes Pod 是 有 生命 周期 的 ， 它 们 可 以 被 创建 ， 也 可 以 被 销毁 ， 然 而 一 旦 被 

销毁 生命 就 永远 结束 。 通过 ReplicationController 能 够 动态 地 创建 和 销毁 
Pod (例如 ， 需 要 进行 扩 缩 容 ， 或 者 执行 滚动 升级 ) © 每 个 Pod 都 会 获取 它 
自己 的 IP 地 址 ， 即 使 这 些 IP 地 址 不 总 是 稳定 可 依赖 的 。 这 会 导致 一 个 问题 : 在 
Kubernetes 集群 中 ， 如 果 一 组 Pod (RX backend) 为 其 它 Pod ( 称 为 
frontend) 提供 服务 ， 那 么 那些 frontend 该 如 何 发 现 ， 并 连接 到 这 组 Pod 中 的 哪 
些 backend 呢 ? 


关于 Service 


Kubernetes Service Poll 一 个 Pod 的 逻辑 分 组 ， 一 种 可 以 
访问 它 常 称 为 微服 务 。 这 一 组 Pod 能 够 被 Service 访问 
到 ， 通 常 是 通过 Label Selector (查看 下 面 了 解 ， 为 什么 可 能 需要 没有 
selector 的 Service ) 实现 的 。 





举 个 例子 ， 考 虑 一 个 图 片 处 理 backend， 它 运行 了 3 个 副本 。 这 些 副本 是 可 互 换 的 

— frontend 不 需要 关心 它们 调用 了 哪个 backend 副本 。 然而 组 成 这 一 组 

backend 程序 的 Pod 实际 上 可 能 会 发 生变 化 ，frontend 客户 端 不 应 该 也 没 必 要 知 
道 ， 而 且 也 不 需要 跟踪 这 一 组 backend 的 状态 。 Service 定义 的 抽象 能 够 解 耦 
这 种 关联 。 

对 Kubernetes 集群 中 的 应 用 ，Kubernetes 提供 了 简单 的 Endpoints API? A € 
Service 中 的 一 组 Pod 发 生变 更 ， 应 用 程序 就 会 被 更 新 。 对 非 Kubernetes 集 


群 中 的 应 用 ，Kubernetes 提供 了 基于 VIP 的 网 桥 的 方式 访问 Service ^ HW 
Service 重 定向 到 backend Pod 。 


Æ SL Service 

一 个 Service 在 Kubernetes 中 是 一 个 REST 对 象 ， 和 Pod 类 似 。 像 所 有 的 

REST 对 象 一 样 ， Service 定义 可 以 基于 POST 方式 ， 请 求 apiserver 创建 新 的 
实例 。 例如 ， 假 定 有 一 组 Pod ， 它 们 对 外 暴露 了 9376 端口 ， 同 时 还 被 打上 
"app=MyApp" 标签 。 


kind: Service 
apiVersion: vi 
metadata: 
name: my-service 
spec: 
selector: 
app: MyApp 
ports: 
- protocol: TCP 
port: 80 
targetPort: 9376 


上 述 配置 将 创建 一 个 名 称 为 “my-service" 的 Service 对 象 ， 它 会 将 请 求 代 理 到 
使 用 TCP 端口 9376， 并 且 具 有 标签 "app-MyApp" 的 Pod 上 。 这 个 
Service 将 被 指派 一 个 IP 地 址 (通常 称 为 “Cluster IP”) ， 它 会 被 服务 的 代理 使 
用 (WFE) 。 该 Service 的 selector 将 会 持续 评估 ， 处 理 结果 将 被 POST 到 
一 个 名 称 为 “my-service” 的 Endpoints 对 象 上 。 


需要 注意 的 是 ， Service 能 够 将 一 个 接收 端口 映射 到 任意 的 targetPort ° R 
认 情 况 下 ， targetPort 将 被 设置 为 与 port 字段 相同 的 值 。 可 能 更 有 趣 的 
是 ，targetPort 可 以 是 一 个 字符 串 ， 引 用 了 backend Pod 的 一 个 端口 的 名 
称 。 但是， 实际 指派 给 该 端口 名 称 的 端口 号 ， 在 每 个 backend Pod 中 可 能 并 不 
相同 。 对 于 部 署 和 设计 Service ， 这 种 方式 会 提供 更 大 的 灵活 性 。 例如 ， 可 以 
在 backend 软件 下 一 个 版 本 中 ， 修 改 Pod 暴露 的 端口 ， 并 不 会 中 断 客户 端的 调 
用 。 


Kubernetes Service 能 够 支持 TCP 和 UDP WN’ RIU TCP 协议 。 


没有 selector 的 Service 


Service 抽象 了 该 如 何 访 问 Kubernetes Pod ， 但 也 能 够 抽象 其 它 类 型 的 
backend， 例 如 : 


e 项 望 在 生产 环境 中 使 用 外 部 的 数据 库 集群 ， 但 测试 环境 使 用 自己 的 数据 库 。 

e 和 希望 服务 指向 另 一 个 Namespace 中 或 其 它 集群 中 的 服务 。 

e 正在 将 工作 负载 转移 到 Kubernetes 集群 ， 和 运行 在 Kubernetes 集群 之 外 的 
backend -° 


在 任何 这 些 场景 中 ， 都 能 够 定义 没有 selector 49 Service 


kind: Service 
apiVersion: vi 


metadata: 
name: my-service 
spec: 
ports: 
- protocol: TCP 
port: 80 


targetPort: 9376 


由 于 这 个 Service 没有 selector， 就 不 会 创建 相关 的 Endpoints 对 象 。 可 以 
手动 将 Service 映射 到 指定 的 Endpoints 


kind: Endpoints 
apiVersion: v1 
metadata: 
name: my-service 
subsets: 
- addresses: 
- ip: 1.2.3.4 
ports: 
- port: 9376 


注意 : Endpoint IP 地 址 不 能 是 loopback (127.0.0.0/8) ^ link- 
local (169.254.0.0/16) ` X4 link-local 44% (224.0.0.0/24) ° 


访问 没有 selector 的 Service * 54 selector 49 Service 的 原理 相同 。 请 求 
将 被 路 由 到 用 户 定义 的 Endpoint (该 示例 中 为 1.2.3.4:9376 ) ° 


ExternalName Service Service 的 特例 ， 它 没有 selector， 也 没有 定义 任 
何 的 端口 和 Endpoint。 相反 地 ， 对 于 运行 在 集群 外 部 的 服务 ， 它 通过 返回 该 外 部 
服务 的 别名 这 种 方式 来 提供 服务 。 


kind: Service 
apiVersion: v1 
metadata: 
name: my-service 
namespace: prod 
spec: 
type: ExternalName 
externalName: my.database.example.com 


4 474 iU my-service.prod.svc.CLUSTER Hj» 4264 DNS 服务 将 返回 一 个 
1&7] my.database.example.com 的 CNAME 记录 。 访问 这 个 服务 的 工作 方式 
与 其 它 的 相同 ， 唯 一 不 同 的 是 重 定向 发 生 在 DNS 层 ， 而 且 不 会 进行 代理 或 转发 。 
如 果 后 续 决 定 要 将 数据 库 迁 移 到 Kubernetes 集群 中 ， 可 以 启动 对 应 的 Pod， 增 加 
合适 的 Selector 或 Endpoint， 修 改 Service 的 type ° 


VIP 和 Service 代理 


在 Kubernetes 集群 中 ， 每 个 Node 运行 一 个 kube-proxy 进程 。 kube-proxy 
负责 为 Service 实现 了 一 种 VIP (ÆW IP) 的 形式 ， 而 不 是 _ ExternalName 
的 形式 。 在 Kubernetes v1.0 版 本 ， 代 理 完 全 在 userspace。 在 Kubernetes v1.1 
版 本 ， 新 增 了 iptables 代理 ， 但 并 不 是 默认 的 运行 模式 。 从 Kubernetes v1.2 起 ， 
SUA 3L iptables 代理 。 


在 Kubernetes v1.0 版 本 ， Service 是 “4 层 ”(TCP/UDP over IP) 概念 。 在 
Kubernetes v1.1 版 本 ， 新 增 了 Ingress API (beta 版 ) ， 用 来 表示 “7 
Æ” (HTTP) 服务 。 


userspace 代理 模式 


这 种 模式 ，kube-proxy 会 监视 Kubernetes master 对 Service 对 象 和 
Endpoints 对 象 的 添加 和 移 除 。 对 每 个 Service ， 它 会 在 本 地 Node 上 打开 
一 个 端口 (随机 选择 ) o 任何 连接 到 “代理 端口 "的 请 求 ， 都 会 被 代理 到 Service 
的 backend Pods 中 的 某 个 上 面 (如 Endpoints 所 报告 的 一 样 ) 。 使 用 哪个 
backend Pod ， 是 基于 Service 的 SessionAffinity 来 确定 的 。 RA’ € 
安装 iptables 规则 ， 捕 获 到 达 该 Service 的 clusterIP (是 虚拟 IP) 和 
Port 的 请 求 ， 并 重 定 向 到 代理 端口 ， 代 理 端口 再 代理 请 求 到 backend Pod e 


网 络 返 回 的 结果 是 ， 任 何 到 达 Service 的 IP:Port 的 请 求 ， 都 会 被 代理 到 一 个 合 
164) backend， 不 需要 客户 端 知道 关于 Kubernetes ^ Service ^ 3X4 Pod 的 任 
何 信息 。 


默认 的 策略 是 ， 通 过 round-robin 算法 来 选择 backend Pod ° 实现 基于 客户 端 IP 
的 会 话 亲 和 性 ， 可 以 通过 设置 service.spec.sessionAffinity 的 值 为 
"ClientIP" 《默认 值 为 "None" ) œ 





Node 


apiserver 











图 片 - userspace. Eik X, T Servicetit 3i, Æ 


iptables 代理 模式 


这 种 模式 ，kube-proxy 会 监视 Kubernetes master * Service 对 象 和 
Endpoints 对 象 的 添加 和 移 除 。 对 每 个 Service ， 它 会 安装 iptables 规则 ， 
从 而 捕获 到 达 该 Service 的 clusterIP (虚拟 IP) 和 端口 的 请 求 ， 进 而 将 请 
求 重 定向 到 service 的 一 组 backend 中 的 某 个 上 面 。 对 于 每 个 Endpoints 对 

象 ， 它 也 会 安装 iptables 规则 ， 这 个 规则 会 选择 一 个 backend Pod 。 


默认 的 策略 是 ， 随 机 选择 一 个 backend。 实现 基于 客户 端 IP 的 会 话 亲 和 性 ， 可 以 
将 service.spec.sessionAffinity 的 值 设置 为 "ClientIP" (默认 值 为 
"Nonen ) E 


和 userspace 代理 类 似 ， 网 络 返回 的 结果 是 ， 任 何 到 达 Service 的 1IP:Port 的 请 
求 ， 都 会 被 代理 到 一 个 合适 的 backend， 不 需要 客户 端 知道 关于 

Kubernetes ^ Service `Ñ Pod 的 任何 信息 。 这 应 该 比 userspace 代理 更 
快 、 更 可 靠 。 然 而 ， 不 像 userspace 代理 ， 如 果 初 始 选择 的 Pod 没有 响应 ， 
iptables 代理 不 能 自动 地 重 试 另 一 个 Pod ， 所 以 它 需要 依赖 readiness probes 。 


Service 





EH -iptables #242 A, T Serviced % A 


% 34,2 Service 


很 多 Service 需要 暴露 多 个 端口 。 对 于 这 种 情况 ，Kubernetes 支持 在 
Service 对 象 中 定义 多 个 端口 。 当 使 用 多 个 端口 时 ， 必 须 给 出 所 有 的 端口 的 名 
称 ， 这 样 Endpoint 就 不 会 产生 歧义 ， 例 如 : 


kind: Service 
apiVersion: vi 


metadata: 
name: my-service 
spec: 
selector: 
app: MyApp 
ports: 
- name: http 
protocol: TCP 
port: 80 


targetPort: 9376 
- name: https 
protocol: TCP 
port: 443 
targetPort: 9377 
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选择 自己 的 IP 地 址 


在 Service 创建 的 请 求 中 ， 可 以 通过 设置 spec.clusterIP 字段 来 指定 自己 
的 集群 IP 地址 。 比如 ， 希 望 替换 一 个 已 经 已 存在 的 DNS 条 目 ， 或 者 遗留 系统 已 
经 配置 了 一 个 固定 的 IP 且 很 难 重 新 配置 。 用 户 选 择 的 P 地址 必须 合法 ， 并 且 这 个 
IP 地 址 在 ”service-cluster-ip-range CIDR 范围 内 ， 这 对 API Server 来 说 是 
通过 一 个 标识 来 指定 的 。 如果 IP 地 址 不 合法 ，API Server 会 返回 HTTP KAY 
422， 表 示 值 不 合法 。 


为 何不 使 用 round-robin DNS? 


一 个 不 时 出 现 的 问题 是 ， 为 什么 我 们 都 使 用 VIP 的 方式 ， 而 不 使 用 标准 的 round- 
robin DNS， 有 如 下 几 个 原因 : 


e 长 久 以 来 ，DNS 库 都 没 能 认真 对 待 DNS TTL、 缓 存 域名 查询 结果 
e 很 多 应 用 只 查询 一 次 DNS 并 缓存 了 结果 
o 就 算 应 用 和 库 能 够 正确 查询 解析 ， 每 个 客户 端 反复 重 解 析 造 成 的 负载 也 是 
非常 难以 管理 的 


我 们 尽力 阻止 用 户 做 那些 对 他 们 没有 好 处 的 事情 ， 如 果 很 多 人 都 来 问 这 个 问题 ， 我 
们 可 能 会 选择 实现 它 。 
服务 发 现 


Kubernetes 支持 2 种 基本 的 服务 发 现 模 式 环境 变量 和 DNS © 





> 


环境 变量 


当 Pod 运行 在 Node 上 ，kubelet 会 为 每 个 活跃 的 Service 添加 一 组 环境 变 
量 。 它 同时 支持 Docker links 兼容 变量 (查看 makeLinkVariables) 、 简 单 的 
{SVCNAME}_SERVICE_HOST 和 {SVCNAME}_SERVICE_PORT 变量 ， 这 里 
Service 的 名 称 需 大 写 ， 横 线 被 转换 成 下 划 线 。 


举 个 例子 ， 一 个 名 称 为 "redis-master" 的 Service HA T TCP 端口 6379， 同 
时 给 它 分 配 了 Cluster IP 地 址 10.0.0.11 > 3X 4- Service 生成 了 如 下 环境 变量 : 


REDIS_MASTER_SERVICE_HOST=10.0.0.11 
REDIS_MASTER_SERVICE_PORT=6379 

REDIS MASTER PORT-tcp://10.0.0.11:6379 

REDIS MASTER PORT 6379 TCP-tcp://10.0.0.11:6379 
REDIS MASTER PORT 6379 TCP PROTO-tcp 

REDIS MASTER PORT 6379 TCP PORT-6379 

REDIS MASTER PORT 6379 TCP ADDR-10.0.0.11 














这 意味 着 需要 有 顺序 想 要 访问 的 任何 Service 必须 在 Pod 
自己 之 前 被 创建 ， a 些 环境 变量 就 不 会 被 赋值 。DNS 并 没有 这 个 限制 。 





DNS 


一 个 可 选 (尽管 强烈 推荐 ) 集群 插件 是 DNS 服务 器 。 DNS 服务 器 监视 着 创建 新 
Service 的 Kubernetes API， 从 而 为 每 一 个 Service 创建 一 组 DNS 记录 。 
如 果 整 个 集群 的 DNS 一 直 被 启用 ， 那 么 所 有 的 Pod 应 该 能 够 自动 对 Service 

进行 名 称 解析 。 


例如 ， 有 一 个 名 称 为 "my-service" 的 Service ， 它 在 Kubernetes 集群 中 名 
为 "my-ns" 的 Namespace 中 ， 为 "my-service.my-ns" a 
记录 。 在 名 称 为 "my-ns" 的 Namespace 中 的 Pod 应 该 能 够 简单 地 通过 名 称 
查询 找到 "my-service" 。 在 另 一 个 Namespace 中 的 Pod ie 限定 名 称 为 
"my-service.my-ns" 。 这 些 名 称 查询 的 结果 是 Cluster IP ° 


Kubernetes 也 支持 对 端口 名 称 的 DNS SRV (Service) 记录 。 如 果 名 称 为 "my- 
service.my-ns" Service 有 一 个 名 为 "http" 的 TCP 端口 ， 可 以 对 
" http. tcp.my-service.my-ns" 执行 DNS SRV 查询 ， 得 到 "http" 的 端 
口号 。 


Kubernetes DNS 服务 器 是 唯一 的 一 种 能 够 访问 ExternalName 类 型 的 Service 
的 方式 。 更 多 信息 可 以 查看 DNS Pod 和 Service » 


Headless Service 


有 时 不 需要 或 不 想 要 负载 均衡 ， 以 及 单独 的 Service IP。 遇 到 这 种 情况 ， 可 以 通过 
指定 Cluster IP ( spec.clusterIP ) 的 值 为 "None" 来 创建 Headless 
Service ° 


这 个 选项 允许 开发 人 员 自 由 寻找 他 们 自己 的 方式 ， 从 而 降低 与 Kubernetes 系统 的 
耦合 性 。 应 用 仍然 可 以 使 用 一 种 自 注 册 的 模式 和 适配器 ， 对 其 它 需 要 发 现 机 制 的 系 
统 能 够 很 容易 地 基于 这 个 AP| 来 构建 


对 这 类 Service 并 不 会 分 配 Cluster IP > kube-proxy 不 会 处 理 它们 ， 而 且 平 台 也 
不 会 为 它们 进行 负载 均衡 和 路 由 。 DNS 如 何 实现 自动 配置 ， 依 赖 于 Service 是 
4 X 3 selector 。 


配置 Selector 


对 定义 了 selector 的 Headless Service * Endpoint 控制 器 在 API 中 创建 了 
Endpoints 记录 ， 并 且 修 改 DNS 配置 返回 A 记录 (地 址 ) ， 通 过 这 个 地 址 直接 
到 达 Service 的 后 端 Pod 上 。 


不 配置 Selector 


对 没有 定义 selector 的 Headless Service，Endpoint 控制 器 不 会 创建 
Endpoints 记录 。 然而 DNS 系统 会 查找 和 配置 ， 无 论 是 : 


e ExternalName 类 型 Service 的 CNAME 记录 
o 记录 : 与 Service 共享 一 个 名 称 的 任何 Endpoints ， 以 及 所 有 其 它 类 型 


发 布 服务 一 一 服务 类 型 


对 一 些 应 用 (如 Frontend) 的 某 些 部 分 ， 可 能 希望 通过 外 部 (Kubernetes 集群 外 
部 ) IP 地 址 暴露 Service ° 


Kubernetes ServiceTypes 允许 指定 一 个 需要 的 类 型 的 Service， 上 默认 是 
ClusterIP 类 型 。 


Type 的 取 值 以 及 行为 如 下 


e ClusterIP : 通过 集群 的 内 部 IP 暴露 服务 ， 选 择 该 值 ， 服 务 只 能 够 在 集群 内 
部 可 以 访问 ， en ServiceType ° 

e NodePort :通过 每 个 Node 上 的 IP Fi 4&3 9 ( NodePort ) 暴露 服 
务 。 NodePort 服务 会 路 由 到 ClusterIP 服务 ， 这 个 ClusterIP 服务 
会 自动 创建 。 通 过 请 求 <NodeIP>:<NodePort> ， 可 以 从 集群 的 外 部 访问 一 
个 NodePort 服务 。 


e LoadBalancer : 使 用 云 提供 商 的 负载 均衡 器 ， 可 以 向 外 部 暴露 服务 。 外 部 
的 负载 均衡 器 可 以 路 由 到 NodePort 服务 和 ClusterIP 服务 。 

e ExternalName : 通过 返回 CNAME 和 它 的 值 ， 可 以 将 服务 映射 到 
externalName 字段 的 内 容 (例如 ， foo.bar.example.com ) » 没有 任 
何 类 型 代理 被 创建 ， 这 只 有 Kubernetes 1.7 或 更 高 版 本 的 kube-dns FX 
持 。 


NodePort 类 型 


如 果 设置 type 的 值 为 "NodePort" > Kubernetes master 将 从 给 定 的 配置 范围 
内 (RU : 30000-32767) 分 配 端 口 ， 每 个 Node 将 从 该 端口 (每 个 Node 上 的 同 

一 端口 ) 代理 到 Service 。 该 端口 将 通过 Service 的 
spec.ports[*].nodePort 字段 被 指定 。 


如 果 需 要 指定 的 端口 号 ， 可 以 配置 nodePort 的 值 ， 系统 将 分 配 这 个 端口 ， 否 则 
调用 API 将 会 失败 (比如 ， 需 要 关心 端口 冲突 的 可 能 性 ) e 

这 可 以 让 开发 人 员 自 由 地 安装 他 们 自己 的 负载 均衡 器 ， 并 配置 Kubernetes 不 能 完 
全 支持 的 环境 参数 ， 或 者 直接 暴露 一 个 或 多 个 Node 的 IP 地址。 


需要 注意 的 是 ，Service 将 能 够 通过 <NodeIP>:spec.ports[*].nodePort 和 
spec.clusterIp:spec.ports[*].port 而 对 外 可 见 。 


LoadBalancer 类 型 


使 用 支持 外 部 负载 均衡 器 的 云 提供 商 的 服务 ， 设 置 type 的 值 为 
"LoadBalancer" ， 将 为 Service 提供 负载 均衡 器 。 负载 均衡 器 是 异步 创建 

的 ， 关 于 被 提供 的 负载 均衡 器 的 信息 将 会 通过 Service 的 
status.loadBalancer 字段 被 发 布 出 去 。 


kind: Service 
apiVersion: vi 
metadata: 
name: my-service 
spec: 
selector: 
app: MyApp 
ports: 
- protocol: TCP 
port: 80 
targetPort: 9376 
nodePort: 30061 
clusterIP: 10.0.171.239 
loadBalancerIP: 78.11.24.19 
type: LoadBalancer 
status: 
loadBalancer: 
ingress: 
- ip: 146.148.47.155 


来 自 外 部 负载 均衡 器 的 流量 将 直接 打 到 backend Pod 上 ， 不 过 实际 它们 是 如 何 工 
作 的 ， 这 要 依赖 于 云 提 供 商 。 在 这 些 情况 下 ， 将 根据 用 户 设置 的 

loadBalancerIP 来 创建 负载 均衡 器 。 某 些 云 提 供 商 允许 设置 

loadBalancerIP 。 如 果 没 有 设置 loadBalancerIP ， 将 会 给 负载 均衡 器 指派 一 
个 临时 IP。 如 果 设 置 了 loadBalancerIP ， 但 云 提 供 商 并 不 支持 这 种 特性 ， 那 么 
设置 的 loadBalancerIP 值 将 会 被 忽略 掉 。 


AWS 内 部 负载 均衡 器 


在 混合 云 环境 中 ， 有 时 从 虚拟 私有 云 (VPC) 环境 中 的 服务 路 由 流量 是 非常 有 必要 
的 。 可 以 通过 在 Service 中 增加 annotation 来 实现 ， 如 下 所 示 : 


[...] 


metadata: 
name: my-service 
annotations: 


service.beta.kubernetes.io/aws-load-balancer-internal: 0 
.0.0.0/0 
Fees] 


在 水 平分 割 的 DNS 环境 中 ， 需 要 两 个 Service 来 将 外 部 和 内 部 的 流量 路 由 到 
Endpoint 上 。 


AWS SSL 支持 


对 运行 在 AWS 上 部 分 支持 SSL 的 集群 ， 从 1.3 版 本 开始 ， 可 以 为 
LoadBalancer 类 型 的 service 增加 两 个 annotation : 


metadata: 
name: my-service 
annotations: 
service.beta.kubernetes.io/aws-load-balancer-ssl-cert: a 
rn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234 
-1234-123456789012 


% — annotation 指定 了 使 用 的 证 书 。 它 可 以 是 第 三 方 发 行商 发 行 的 证 书 ， 这 个 证 
书 或 者 被 上 传 到 IAM， 或 者 由 AWS 的 证 书 管理 器 创建 。 


metadata: 
name: my-service 
annotations: 
service. beta. kubernetes.io/aws-load-balancer -backend-pr 
otocol: (https|http|ssl|tcp) 


第 二 个 annotation 指定 了 Pod 使 用 的 协议 。 对 于 HTTPS 和 SSL * ELB 将 期 望 
该 Pod 基于 加 蜜 的 连接 来 认证 自身 。 


HTTP 和 HTTPS 将 选择 7 层 代 理 : ELB 将 中 断 与 用 户 的 连接 ， 当 转发 请 求 时 ， 会 
解析 Header 信息 并 添加 上 用 户 的 IP 地 址 ( Pod 将 只 能 在 连接 的 另 一 端 看 到 该 
IP 地 址 ) 。 


TCP 和 SSL 将 选择 4 层 代理 : ELB 将 转发 流量 ， 并 不 修改 Header 信息 。 


外 部 IP 


如 果 外 部 的 [P 路 由 到 集群 中 一 个 或 多 个 Node 上 ，Kubernetes Service 会 被 暴 
露 给 这 些 externalIPs ° 通过 外 部 IP (作为 目的 IP 地 址 ) 进入 到 集群 ， 打 到 
Service 的 端口 上 的 流量 ， 将 会 被 路 由 到 Service 4 Endpoint 上 。 
externalIPs 不 会 被 Kubernetes 管理 ， 它 属于 集群 管理 员 的 职责 范畴 。 


根据 Service 的 规定 ， externalIPs 可 以 同 任意 的 ServiceType 来 一 起 指 
Zo 在 下 面 的 例子 中 ， my-service 可 以 在 80.11.12.10:80 (外 部 IP: 0 ) 上 被 
客户 端 访问 。 


kind: Service 
apiVersion: vi 
metadata: 
name: my-service 
spec: 
selector: 
app: MyApp 
ports: 
- name: http 
protocol: TCP 
port: 80 
targetPort: 9376 
externalIPs: 
- 80.11.12.10 


AREA 


A VIP 使 用 userspace 代理 ， 将 只 适合 小 型 到 中 型 规模 的 集群 ， 不 能 够 扩展 到 上 千 
Service 的 大 型 集群 。 查 看 最 初 设计 方案 获取 更 多 细节 。 


使 用 userspace 代理 ， 隐 藏 了 访问 Service 的 数据 包 的 源 IP 地址。 这 使 得 一 些 
类 型 的 防火 墙 无 法 起 作用 © iptables 代理 不 会 隐藏 Kubernetes 集群 内 部 的 IP 地 
址 ， 但 却 要 求 客户 端 请 求 必须 通过 一 个 负载 均衡 器 或 Node 端口 。 





Type 字段 支持 话 套 功能 每 一 层 需要 添加 到 上 一 层 里 面 。 不 会 严格 要 求 所 有 
云 提 供 商 (例如 ，GCE 就 没 必要 为 了 使 一 个 LoadBalancer 能 工作 而 分 配 一 个 
NodePort ， 但 是 AWS 需要 ) ， 但 当前 API 是 强制 要 求 的 。 


未 来 工作 


未 来 我 们 能 预见 到 ， 代 理 策略 可 能 会 变 得 比 简单 的 round-robin 均衡 策略 有 更 多 细 
微 的 差别 ， 比 如 master 选举 或 分 片 。 我 们 也 能 想到 ， 某 些 Service BAA “4 
E” 的 负载 均衡 器 ， 这 种 情况 下 VIP 将 简化 数据 包 的 传输 。 


我 们 打算 为 L7 (HTTP) Service 改进 我 们 对 它 的 支持 。 


我 们 打算 为 Service 实现 更 加 灵活 的 请 求 进 入 模式 ， 这 些 Service 包含 当前 
ClusterIP ^ NodePort 和 LoadBalancer 模式 ， 或 者 更 多 。 


VIP 的 那些 骇人听闻 的 细节 


对 很 多 想 使 用 Service 的 人 来 说 ， 前 面 的 信息 应 该 足够 了 。 然而 ， 有 很 多 内 部 
原理 性 的 内 容 ， 还 是 值 去 理解 的 。 


iE RIP OR 


Kubernetes 最 主要 的 哲学 之 一 ， 是 用 户 不 应 该 暴露 那些 能 够 导致 他 们 操作 失败 、 但 
又 不 是 他 们 的 过 错 的 场景 。 这 种 场景 下 ， 让 我 们 来 看 一 下 网 络 端口 一 ”用户 不 应 
该 必须 选择 一 个 端口 号 ， 而 且 该 端口 还 有 可 能 与 其 他 用 户 的 冲突 。 这 就 是 说 ， 在 彼 
此 隔离 状态 下 仍然 会 出 现 失败 。 


为 了 使 用 户 能 够 为 他 们 的 Service 选择 一 个 端口 号 ， 我 们 必须 确保 不 能 有 2 个 
Service 发 生 冲 突 。 我 们 可 以 通过 为 每 个 Service 分 配 它们 自己 的 IP 地 址 来 
实现 。 


为 了 保证 每 个 Service 被 分 配 到 一 个 唯一 的 IP， 需要 一 个 内 部 的 分 配器 能 够 原 
子 地 更 新 etcd 中 的 一 个 全 局 分 配 映射 表 ， 这 个 更 新 操作 要 先 于 创建 每 一 个 
Service 。 为 了 使 Service 能 够 获取 到 IP， 这 个 映射 表 对 象 必须 在 注册 中 心 
存在 ， 否 则 创建 service 将 会 失败 ， 指 示 一 个 IP 不 能 被 分 配 。 一 个 后 台 
Controller 的 职责 是 创建 映射 表 (从 Kubernetes 的 昌 版 本 迁移 过 来 ， 旧 版 本 中 是 通 
过 在 内 存 中 加 锁 的 方式 实现 ) ， 并 检查 由 于 管理 员 干 预 和 清除 任意 IP 造成 的 不 合 
理 分 配 ， 这 些 JP 被 分 配 了 但 当前 没有 Service 使 用 它们 。 


IP 和 VIP 


T Pod 的 IP 地 址 ， 它 实际 路 由 到 一 个 国定 的 目的 地 ， Service 4 IP 实际 上 
不 能 通过 单个 主机 来 进行 应 答 。 相反， 我 们 使 用 iptables (Linux 中 的 数据 包 
HH) 来 定义 一 个 虚拟 IP 地 址 (VIP) ， 它 可 以 根据 需要 透明 地 进行 重 定向 。 
当 客 户 端 连 接 到 VIP 时 ， 它 们 的 流量 会 自动 地 传输 到 一 个 合适 的 Endpoint 。 环境 
变量 和 DNS， 实 际 上 会 根据 Service 的 VIP 和 端口 来 进行 填充 。 


Userspace 


作为 一 个 例子 ， 考 虑 前 面 提 到 的 图 片 处 理应 用 程序 。 当 创 建 backend Service 
时 ，Kubernetes master 会 给 它 指派 一 个 虚拟 IP 地 址 ， 比 如 10.0.0.1。 假设 
Service 的 端口 是 1234， 该 Service 会 被 集群 中 所 有 的 kube-proxy 实例 
观察 到 。 当代 理 看 到 一 个 新 的 Service ， 它 会 打开 一 个 新 的 端口 ， 建 立 一 个 从 
该 VIP 重 定向 到 新 端口 的 iptables， 并 开始 接收 请 求 连接 。 


当 一 个 客户 端 连 接 到 一 个 VIP，iptables 规则 开始 起 作用 ， 它 会 重 定向 该 数据 包 到 
Service 代 理 的 端口 。 Service 代 理 选择 一 个 backend， 并 将 客户 端的 流量 代 
3€ $| backend 上 。 


这 意味 着 Service 的 所 有 者 能 够 选择 任何 他 们 想 使 用 的 端口 ， 而 不 存在 冲突 的 风 
险 。 客户 端 可 以 简单 地 连接 到 一 个 IP 和 端口 ， 而 不 需要 知道 实际 访问 了 哪些 
Pod ° 


Iptables 


再 次 考虑 前 面 提 到 的 图 片 处 理应 用 程序 。 当 创 建 backend Service 时 ， 
Kubernetes master 会 给 它 指派 一 个 虚拟 IP 地 址 ， 比 如 10.0.0.1。 假设 

Service 的 端口 是 1234， 该 Service 会 被 集群 中 所 有 的 kube-proxy 实例 
观察 到 。 当代 理 看 到 一 个 新 的 Service ， 它 会 安装 一 系列 的 iptables 规则 ， 从 
VIP 重 定 向 到 per- Service 规则 。 该 per- Service 规则 连接 到 

per- Endpoint 规则 ， 该 per- Endpoint 规则 会 重 定向 (目标 NAT) 到 
backend ° 


当 一 个 客户 端 连 接 到 一 个 VIP，iptables 规则 开始 起 作用 。 一 个 backend 会 被 选择 
(或 者 根据 会 话 亲 和 性 ， 或 者 随机 ) ， 数 据 包 被 重 定向 到 这 个 backend ». 不 像 
userspace 代理 ， 数 据 包 从 来 不 拷贝 到 用 户 空 间 ，kube-proxy 不 是 必须 为 该 VIP 工 
作 而 运行 ， 并 且 客 户 端 IP 是 不 可 更 改 的 。 当 流 量 打 到 Node 的 端口 上 ， 或 通过 负 
载 均 衡器 ， 会 执行 相同 的 基本 流程 ， 但 是 在 那些 案例 中 客户 端 IP 是 可 以 更 改 的 。 


API 对 象 
在 Kubernetes REST API 中 ，Service X top-level 资源 。 关 于 API 对 象 的 更 多 细 
节 可 以 查看 : Service API 对 象 。 
更 多 信息 
e 使 用 Service 连接 Frontend 到 Backend 
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3i X kubernete È 7 X44 P Ingress Resource 的 翻译 ， 后 面 的 章节 会 讲 到 使 用 Traefik 
来 做 Ingress controller， 文 章 末 尾 给 出 了 几 个 相关 链接 。 


术语 
在 本 篇 文章 中 你 将 会 看 到 一 些 在 其 他 地 方 被 交叉 使 用 的 术语 ， 为 了 防止 产生 歧义 ， 
我 们 首先 来 洪 清 下 。 


e 节点 : Kubernetes 集 群 中 的 一 台 物 理 机 或 者 虚拟 机 。 

e 集群 : 位 于 Internet 防 火 墙 后 的 节点 ， 这 是 kubernetes 管 理 的 主要 计算 资源 。 

e 边界 路 由 器 : 为 集群 强制 执行 防火 墙 策 略 的 路 由 器 。 这 可 能 是 由 云 提 供 商 或 物 
理 硬件 管理 的 网 关 。 

e 集群 网 络 : 一 组 逻辑 或 物理 链接 ， 可 根据 Kubernetes 网 络 模型 实现 群集 内 的 通 
信 。 集群 网 络 的 实现 包括 Overlay 模 型 的 flannel 和 基于 SDN 的 OVS。 

e 服务 : 使 用 标签 选择 器 标识 一 组 pod 成 为 的 Kubernetes 服 务 。 除非 另 有 说 明 ， 
否则 服务 假定 在 集群 网 络 内 仅 可 通过 虚拟 IP 访 问 。 


什么 是 Ingress ? 


通常 情况 下 ，service 和 pod 仅 可 在 集群 内 部 网 络 中 通过 |P 地 址 访问 。 所 有 到 达 边 界 
路 由 器 的 流量 或 被 丢弃 或 被 转发 到 其 他 地 方 。 从 概念 上 讲 ， 可 能 像 下 面 这 样 : 


internet 


[ Services | 


Ingress 是 授权 入 站 连接 到 达 集 群 服务 的 规则 集合 。 


internet 


[ Ingress ] 


[ Services ] 


你 可 以 给 Ingress 配 置 提 供 外 部 可 访问 的 URL、 负 载 均 衡 、SSL、 基 于 名 称 的 虚拟 主 
机 等 。 用 户 通 过 POST Ingress 资 源 到 API server 的 方式 来 请 求 ingress。 Ingress 
controller 负 责 实 现 Ingress， 通 常 使 用 负载 平衡 器 ， 它 还 可 以 配置 边界 路 由 和 其 他 前 
端 ， 这 有 助 于 以 HA 方式 处 理 流量 。 


先决 条 件 


在 使 用 Ingress resource 之 前 ， 有 必要 先 了 解 下 面 几 件 事情 。|ngress 是 beta 版 本 的 
resource， 在 kubernetes1.1 之 前 还 没有 。 你 需要 一 个 Ingress Controller 来 实 
现 Ingress ， 单 纯 的 创建 一 个 Ingress 没有 任何 意义 。 


GCE/GKE 会 在 master 节 点 上 部 署 一 个 ingress controller。 你 可 以 在 一 个 pod 中 部 署 
任意 个 自 定 义 的 ingress controller。 你 必须 正确 地 annotate 每 个 ingress， 比 如 运行 
多 个 ingress controller 和 关闭 glbc. 


确定 你 已 经 阅读 了 lngress controller 的 beta 版 本 限制 。 在 非 GCE/GKE 的 环境 中 ， 你 
$ 2 pod f #8 4 — controller 。 


Ingress Resource 


最 简化 的 Ingress 配 置 : 


1: apiVersion: extensions/vibeta1 
2: kind: Ingress 

3: metadata: 

4: name: test-ingress 

5i Spec: 

6: rules: 

T: - http: 

8: paths: 

9: - path: /testpath 

10: backend: 

11: serviceName: test 


12: servicePort: 80 


如 果 你 没有 配置 /ngress controllers. 3t HPOST2IAPI server 不 会 有 任何 用 处 
配置 说 明 


1-441 : 跟 Kubernetes 的 其 他 配置 一 样 ，ingress 的 配置 也 需 
要 apiVersion ° kind 和 metadata 字段 。 配 置 文件 的 详细 说 明 请 查看 部 署 应 
用 ,配置 容器 和 使 用 resources. 


5-7 行 : Ingress spec 中 包含 配置 一 个 loadbalancer 或 proxy server 的 所 有 信息 。 最 重 
要 的 是 ， 它 包含 了 一 个 匹配 所 有 入 站 请 求 的 规则 列表 。 目 前 ingress 只 支持 http 规 
H] o 


8-947 : 每 条 http 规 则 包含 以 下 信息 : 一 个 host 配置 项 (比如 for.bar.com， 在 这 个 
例子 中 默认 是 *) * path 列表 (上 比如 : /testpath) ， 每 个 path 都 关联 一 

个 backend (比如 test:80)。 在 loadbalancer 将 流量 转发 到 backend 之 前 ， 所 有 的 入 
站 请 求 都 要 先 匹配 host 和 path。 


10-1241 : 正如 services doc 中 描述 的 那样 ，backend 是 一 个 service:port 的 组 
合 。Ingress 的 流量 被 转发 到 它 所 匹配 的 backend 。 


全 局 参数 : 为 了 简单 起 见 ，lIngress 示 例 中 没有 全 局 参数 ， 请 参阅 资源 完整 定义 的 
api 参 考 。 在 所 有 请 求 都 不 能 跟 spec 中 的 path 匹 配 的 情况 下 ， 请 求 被 发 送 到 Ingress 
controller 的 默认 后 端 ， 可 以 指定 全 局 缺 省 backend 。 


Ingress controllers 


为 了 使 Ingress 正 常 工作 ， 集 群 中 必须 运行 Ingress controller。 这 与 其 他 类 型 的 控制 
器 不 同 ， 其 他 类 型 的 控制 器 通常 作为 kube-controller-manager 二 进 制 文件 的 一 
部 分 运行 ， 在 集群 启动 时 自动 启动 。 你 需要 选择 最 适合 自己 集群 的 Ingress 
controller 或 者 自己 实现 一 个 。 示 例 和 说 明 可 以 在 这 里 找到 。 


在 你 开始 前 


以 下 文档 描述 了 Ingress 资 源 中 公开 的 一 组 跨 平台 功能 。 理 想 情况 下 ， 所 有 的 
Ingress controller 都 应 该 符合 这 个 规范 ， 但 是 我 们 还 没有 实现 。GCE 和 nginx 控 制 
器 的 文档 分 别 在 这 里 和 这 里 。 确 保 您 查看 控制 器 特定 的 文档 ， 以 便 您 了 解 每 个 文档 
的 注意 事项 。 


Ingress X # 


3 Service Ingress 


Kubernetes 中 已 经 存在 一 些 概念 可 以 暴露 单个 service ( S IX SE) ， 但 是 你 仍 
然 可 以 通过 Ingress 来 实现 ， 通 过 指定 一 个 没有 rule 的 黑 认 backend 的 方式 。 


ingress.yaml 定 义 文件 : 


apiVersion: extensions/vibetai 
kind: Ingress 
metadata: 
name: test-ingress 
spec: 
backend: 
serviceName: testsvc 
servicePort: 80 


使 用 kubectl create -f 命令 创建 ， 然 后 查看 ingress : 


$ kubectl get ing 
NAME RULE BACKEND ADDRESS 
test-ingress - testsvc: 80 107.178.254.228 


107.178.254.228 就 是 Ingress controller 为 了 实现 Ingress 而 分 配 的 IP 地 
址 。 RULE 列表 示 所 有 发 送 给 该 IP 的 流量 都 被 转发 到 了 BACKEND 所 列 的 
Kubernetes service_E ° 


简单 展开 


如 前 面 描述 的 那样 ，kubernete pod 中 的 IP 只 在 集群 网 络 内 部 可 见 ， 我 们 需要 在 边界 
设置 一 个 东西 ， 让 它 能 够 接收 ingress 的 流量 并 将 它们 转发 到 正确 的 端点 上 。 这 个 东 
西 一 般 是 高 可 用 的 loadbalancer。 使 用 Ingress 能 够 允许 你 将 loadbalancer 的 个 数 降 

低 到 最 少 ， 例 如 ， 假 如 你 想 要 创建 这 样 的 一 个 设置 : 


foo.bar.com -> 178.91.123.132 -> / foo s1:80 
/ bar s2:80 


你 需要 一 个 这 样 的 ingress : 


apiVersion: extensions/vibeta1 
kind: Ingress 
metadata: 
name: test 
spec: 
rules: 
- host: foo.bar.com 
http: 
paths: 
- path: /foo 
backend: 
serviceName: si 
servicePort: 80 
- path: /bar 
backend: 
serviceName: s2 
servicePort: 80 


使 用 kubectl create -f 创建 完 ingress 后 : 


$ kubectl get ing 


NAME RULE BACKEND ADDRESS 
test - 

foo.bar.com 

/foo s1:80 

/bar s2:80 


只 要 服务 (s1*s2) 44 * Ingress controller 就 会 将 提供 一 个 满足 该 Ingress 的 特定 
loadbalancer 实 现 。 这 一 步 完成 后 ， 您 将 在 Ingress 的 最 后 一 列 看 到 loadbalancer 的 
地 址 。 


基于 名 称 的 虚拟 主机 
Name-based 的 虚拟 主机 在 同一 个 IP 地 址 下 拥有 多 个 主机 名 。 


foo.bar.com --| |-> foo.bar.com s1:80 
| 178.91.123.132 | 
bar.foo.com --| |-> bar.foo.com s2:80 


下 面 这 个 ingress 说 明基 于 Host header 的 后 端 loadbalancer 的 路 由 请 求 : 


apiVersion: extensions/vibeta1 
kind: Ingress 
metadata: 

name: test 
spec: 

rules: 

- host: foo.bar.com 

http: 

paths: 

- backend: 
serviceName: si 
servicePort: 80 

- host: bar.foo.com 
http: 

paths: 

- backend: 
serviceName: s2 
servicePort: 80 


S backend : 一 个 没有 rule 的 ingress， 如 前 面 章 节 中 所 示 ， 所 有 流量 都 将 发 送 到 
一 个 默认 backend。 你 可 以 用 该 技巧 通知 loadbalancer 如 何 找到 你 网 站 的 404 页 面 ， 
通过 制定 一 些 列 rule 和 一 个 默认 backend 的 方式 。 如 果 请 求 header 中 的 host 不 能 跟 
ingress 中 的 host 匹 配 ， 并 且 / 或 请 求 的 URL 不 能 与 任何 一 个 path 匹 配 ， 则 流量 将 路 由 
到 你 的 默认 backend。 


TLS 


你 可 以 通过 指定 包含 TLS 私 钥 和 证 书 的 secret 来 加 密 Ingress。 目 前 ，|ngress 仅 支持 
单个 TLS 端 口 443， 并 假定 TLS termination » 如 果 Ingress 中 的 TLS 配 置 部 分 指定 了 
不 同 的 主机 ， 则 它们 将 根据 通过 SNITLS 扩 展 指定 的 主机 名 〈 假 如 Ingress 
controller X4#SNI) 在 多 个 相同 端口 上 进行 复 用 。TLS secret 中 必须 包含 名 

为 tls.crt 和 tls.key 的 密 钥 ， 这 里 面包 含 了 用 于 TLS 的 证 书 和 私 钥 ， 例 如 : 


apiVersion: vi 
data: 
tls.crt: base64 encoded cert 
tls.key: base64 encoded key 
kind: Secret 
metadata: 
name: testsecret 
namespace: default 
type: Opaque 


Æ Ingress ¥ 4] M 3x ^- secret 34 4 Ingress controller 使 用 TLS 加 密 从 将 客户 端 到 
loadbalancer&5 channel : 


apiVersion: extensions/vibetai 
kind: Ingress 


metadata: 
name: no-rules-map 
spec: 
tis: 
- secretName: testsecret 
backend: 


serviceName: si 
servicePort: 80 


请 注意 ， 各 种 Ingress controller 支 持 的 TLS 功 能 之 间 存 在 差距 。 请 参阅 有 
关 nginx，GCE 或 任何 其 他 平台 特定 Ingress controller 的 文档 ， 以 了 解 TLS 在 你 的 环 
境 中 的 工作 原理 。 


Ingress controller 启 动 时 附带 一 些 适 用 于 所 有 Ingress 的 负载 平衡 策略 设置 ， 例 如 负 

载 均衡 算法 ， 后 端 权重 方案 等 。 更 高 级 的 负载 平衡 概念 〈 例 如 持久 会 话 ， 动 态 权 
重 ) 尚未 在 Ingress 中 公开 。 你 仍然 可 以 通过 service loadbalancer 获 取 这 些 功能 。 

随 着 时 间 的 推移 ， 我 们 计划 将 适用 于 跨 平台 的 负载 平衡 模式 加 入 到 Ingress 资 源 中 。 


还 值得 注意 的 是 ， 尽 管 健康 检查 不 直接 通过 Ingress 公 开 ， ee 
概念 ， 例 如 准备 探查 ， 可 以 使 你 达成 相同 的 最 终结 果 。 请 查看 特定 控制 器 的 文档 ， 
以 了 解 他 们 如 何 处 理 健 康 检查 (nginx，GCE) 。 


更 新 Ingress 
假如 你 想 要 向 已 有 的 ingress 中 增加 一 个 新 的 Host， 你 可 以 编辑 和 更 新 该 ingress : 


$ kubectl get ing 


NAME RULE BACKEND ADDRESS 

test - 178.91.123.132 
foo.bar.com 
/foo s1:80 


$ kubectl edit ing test 


这 会 弹出 一 个 包含 已 有 的 yaml| 文 件 的 编辑 器 ， 修 改 它 ， 增 加 新 的 Host 配 置 。 


spec: 
rules: 
- host: foo.bar.com 
http: 

paths: 

- backend: 
serviceName: si 
servicePort: 80 

path: /foo 
- host: bar.baz.com 
http: 

paths: 

- backend: 
serviceName: s2 
servicePort: 80 

path: /foo 


保存 它 会 更 新 API server Y $5 3E 7$ > ix SAR ingress controller & # & £. 
loadbalancer ° 


$ kubectl get ing 


NAME RULE BACKEND ADDRESS 
test - 178.91.123.132 
foo.bar.com 
/foo s1:80 
bar.baz.com 
/foo s2:80 


在 一 个 修改 过 的 ingress yaml 文 件 上 调用 kubectl replace -f 命令 一 样 可 以 达到 
同样 的 效果 。 
跨 可 用 域 故 障 


在 不 通 云 供应 商 之 间 ， 跨 故障 域 的 流量 传播 技术 有 所 不 同 。 有关 详细 信息 ， 请 查看 
38 XIngress controller 的 文档 。 有 关 在 federation 集 群 中 部 署 Ingress 的 详细 信息 ， 
请 参阅 federation 文 档 。 


未 来 计划 


e 多 样 化 的 HTTPS/TLS 模 型 支持 (如 SNI，re-encryption) 
e 通过 声明 来 请 求 |P 或 者 主机 名 


Ingress 


L4 和 L7 Ingress 


e 结 号 
e 更 多 的 Ingress controller 


请 跟踪 L7 和 |ngress 的 proposal， 了 解 有 关 资 源 演 进 的 更 多 细节 ， 以 及 Ingress 
repository， 了 解 有 关 各 种 Ingress controller 演 进 的 更 多 详细 信息 。 


、 NEN 
替代 方案 
你 可 以 通过 很 多 种 方式 暴露 service 而 不 必 直 接 使 用 ingress : 


e 使 用 Service.Type=LoadBalancer 

e 使 用 Service.Type=NodePort 

e 使 用 Port Proxy 

e 部 署 一 个 Service loadbalancer 这 允许 你 在 多 个 service 之 间 共 享 单个 |P， 并 通 
it Service Annotations 实 现 更 高 级 的 负载 平衡 。 


Kubernetes Ingress Resource 

使 用 NGINX Plus 负 载 均 衡 Kubernetes 服 务 

使 用 NGINX 和 NGINX Plus 的 Ingress Controller 进行 Kubernetes 的 负载 均衡 
Kubernetes : Ingress Controller with TreefIk and Let's Encrypt 

Kubernetes : TreefIk and Let's Encrypt at scale 

Kubernetes Ingress Controller-Traefrk 

Kubernetes 1.2 and simplifying advanced networking with Ingress 
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Traefik Ingress Controller 


我 们 在 前 面部 署 了 Traefik TE A Ingress Controller， 如 果 集 群 外 部 直接 访问 
Kubenretes 内 部 服务 的 话 ， 可 以 直接 创建 Ingress 如 下 所 示 : 


apiVersion: extensions/vibetai 
kind: Ingress 
metadata: 
name: traefik-ingress 
namespace: default 
spec: 
rules: 
- host: traefik.nginx.io 
http: 
paths: 
- path: / 
backend: 
serviceName: my-nginx 
servicePort: 80 


Traefik Ingress Controller 


当 我 们 处 于 迁移 应 用 到 kuberentes 上 的 阶段 时 ， 可 能 有 部 分 服务 实例 不 在 
kubernetes 上 ， 服 务 的 路 由 使 用 nginx 配 置 ， 这 时 处 于 nginx 和 ingress 共 存 的 状态 。 
参考 下 面 的 配置 : 


apiVersion: extensions/vibetai 
kind: Ingress 
metadata: 
name: td-ingress 
namespace: default 
annotations: 
traefik.frontend.rule.type: PathPrefixStrip 
kubernetes.io/ingress.class: traefik 
spec: 
rules: 
- host: "*.jimmysong.io" 
http: 
paths: 
- path: /docGenerate 
backend: 
serviceName: td-sdmk-docgenerate 
servicePort: 80 


注意 annotation 的 配置 : 


e traefik.frontend.rule.type: PathPrefixStrip : 表示 将 截 掉 URL 中 
的 path 
e kubernetes.io/ingress.class : 表示 使 用 的 ingress 类 型 


` 
> 


X F Ingress annotation 的 更 多 信息 请 参考 : Ingress Annotations - kubernetes.io ° 


在 nginx 中 增加 配置 : 


upstream docGenerate { 
server 172.20.0.119:80; 
keepalive 200; 
} 


172.20.0.119 是 我 们 的 边缘 节点 的 VIP， 见 边缘 节点 配置 。 


e Kubernetes Ingress Backend - traefik.io 
e Kubernetes Ingress Controller - traefik.io 
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身份 与 权限 认证 


Kubernetes 中 提供 了 良好 的 多 租户 认证 管理 机 制 ， 如 RBAC、ServiceAccount 还 有 
各 种 Policy 等 。 
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Service Account 


Service account 为 Pod 中 的 进程 提供 身份 信息 。 


本 文 是 关于 Service Account 的 用 户 指南 ， 管 理 指南 另 见 Service Account 的 集群 
管理 指南 。 


注意 : 本 文档 描述 的 关于 Serivce Account 的 行为 只 有 当 您 按照 Kubernetes 项 目 
建议 的 方式 搭建 起 集群 的 情况 下 才 有 效 。 您 的 集群 管理 员 可 能 在 您 的 集群 中 有 自 定 
义 配置 ， 这 种 情况 下 该 文档 可 能 并 不 适用 。 


当 您 RAMP) 访问 集群 (例如 使 用 kubectl A) 时 ，apiserver 会 将 您 认证 
为 一 个 特定 的 User Account (目前 通常 是 admin ， 除 非 您 的 系统 管理 员 自 定义 了 

集群 配置 ) ° Pod 容器 中 的 进程 也 可 以 与 apiserver 联系 。 当 它 们 在 联系 apiserver 
的 时 候 ， 它 们 会 被 认证 为 一 个 特定 的 Service Account (例如 default ) ° 


使 用 默认 的 Service Account 访问 API server 


当 您 创建 pod 的 时 候 ， 如 果 您 没有 指定 一 个 service account， 系 统 会 自动 得 在 与 
该 pod 相同 的 namespace 下 为 其 指派 一 个 default service account。 如 果 您 获 
取 刚 创建 的 pod 的 原始 json 或 yaml 信息 (例如 使 用 kubectl get 
pods/podename -o yaml TA) ， 您 将 看 到 spec.serviceAccountName 字段 已 
经 被 设置 为 automatically set 。 


您 可 以 在 pod 中 使 用 自动 挂 载 的 service account 凭证 来 访问 API， 如 Accessing 
the Cluster 中 所 描述 。 


Service account 是 否 能 够 取得 访问 API 的 许可 取决 于 您 使 用 的 授权 插件 和 策略 。 


在 1.6 以 上 版 本 中 ， 您 可 以 选择 取消 为 service account A HR API Hit RF 
在 service account 中 设置 automountServiceAccountToken: false 


apiVersion: v1 
kind: ServiceAccount 
metadata: 
name: build-robot 
automountServiceAccountToken: false 


在 1.6 以 上 版 本 中 ， 您 也 可 以 选择 只 取消 单个 pod 的 API 凭证 自动 挂 载 : 


apiVersion: vi 

kind: Pod 

metadata: 
name: my-pod 

spec: 
serviceAccountName: build-robot 
automountServiceAccountToken: false 


如 果 在 pod 和 service account 中 同时 设置 了 automountServiceAccount Token 
, pod 设置 中 的 优先 级 更 高 。 


使 用 多 个 Service Account 


每 个 namespace 中 都 有 一 个 上 默认 的 叫做 default 的 service account 资源 。 


您 可 以 使 用 以 下 命令 列 出 namespace 下 的 所 有 serviceAccount 资源 。 


$ kubectl get serviceAccounts 
NAME SECRETS AGE 
default 1 1d 


您 可 以 像 这 样 创建 一 个 ServiceAccount * & : 


$ cat > /tmp/serviceaccount.yaml <<EOF 
apiVersion: vi 
kind: ServiceAccount 
metadata: 
name: build-robot 
EOF 
$ kubectl create -f /tmp/serviceaccount.yaml 
serviceaccount "build-robot" created 


如 果 您 看 到 如 下 的 service account 对 象 的 完整 输出 信息 : 


$ kubectl get serviceaccounts/build-robot -o yaml 
apiVersion: vi 
kind: ServiceAccount 
metadata: 

creationTimestamp: 2015-06-16T00:12:59Z 

name: build-robot 

namespace: default 

resourceVersion: "272500" 

selfLink: /api/vi/namespaces/default/serviceaccounts/build-rob 
ot 

uid: 721ab723-13bc-11e5-aec2-42010af0021e 
secrets: 
- name: build-robot-token-bvbk5 


然后 您 将 看 到 有 一 个 token 已 经 被 自动 创建 ， 并 被 service account 引用 。 
您 可 以 使 用 授权 插件 来 设置 service account 的 权限 。 


设置 非 默 认 的 service account， 只 需要 在 pod 的 spec.serviceAccountName 字 
段 中 将 name 设 置 为 您 想 要 用 的 service account 名 字 即 可 。 


在 pod 创建 之 初 service account 就 必须 已 经 存在 ， 否 则 创建 将 被 拒绝 。 
您 不 能 更 新 已 创建 的 pod 的 service account。 


您 可 以 清理 service account， 如 下 所 示 : 


$ kubectl delete serviceaccount/build-robot 


手动 创建 service account 的 API token 


假设 我 们 已 经 有 了 一 个 如 上 文 提 到 的 名 为 ”build-robot 的 service account * 4&1] + 
动 创建 一 个 新 的 secret 。 


$ cat > /tmp/build-robot-secret.yaml ««EOF 
apiVersion: vi 
kind: Secret 
metadata: 

name: build-robot-secret 

annotations: 

kubernetes.io/service-account.name: build-robot 

type: kubernetes.io/service-account-token 
EOF 
$ kubectl create -f /tmp/build-robot-secret.yaml 
secret "build-robot-secret" created 


现在 您 可 以 确认 下 新 创建 的 secret 取代 了 “build-robot” 这 个 service account 原来 
的 API token ° 


所 有 已 不 存在 的 service account 的 token 将 被 token controller 清理 掉 。 


$ kubectl describe secrets/build-robot-secret 


Name: build-robot-secret 
Namespace: default 
Labels: <none> 


Annotations:  kubernetes.io/service-account.name-build-robot,kub 
ernetes.io/service-account.uid-z870ef2a5-35cf-11e5-8d06-005056b45 
392 


Type: kubernetes.io/service-account-token 


ca.crt: 1220 bytes 
token: 
namespace: 7 bytes 


注意 该 内 容 中 的 token RAST ° 


为 service account 添加 ImagePullSecret 


首先 ， 创 建 一 个 imagePullSecret， 详 见 这 里 。 
然后 ， 确 认 已 创建 。 如 : 
$ kubectl get secrets myregistrykey 


NAME TYPE DATA AGE 
myregistrykey kubernetes.io/.dockerconfigjson 1 1d 


然后 ， 修 改 namespace 中 的 默认 service account 使 用 该 secret 作为 
imagePullSecret ° 


kubectl patch serviceaccount default -p '{"imagePullSecrets": 
"name": "myregistrykey"}]}' 


Vi 交互 过 程 中 需要 手动 编辑 : 


$ kubectl get serviceaccounts default -0 yaml > ./sa.yaml 
$ cat sa.yaml 
apiVersion: v1 
kind: ServiceAccount 
metadata: 
creationTimestamp: 2015-08-07T22:02:39Z 
name: default 
namespace: default 
resourceVersion: "243024" 
selfLink: /api/vi/namespaces/default/serviceaccounts/default 
uid: 052fbOf4-3d50-11e5-b066-42010af0d7b6 
secrets: 
- name: default-token-uudge 
$ vi sa.yaml 
[editor session not shown] 
[delete line with key "resourceVersion"] 
[add lines with "imagePullSecret:"] 
$ cat sa.yaml 
apiVersion: v1 
kind: ServiceAccount 
metadata: 
creationTimestamp: 2015-08-07T22:02:39Z 
name: default 
namespace: default 
selfLink: /api/vi/namespaces/default/serviceaccounts/default 
uid: 052fbOf4-3d50-11e5-b066-42010af0d7b6 
secrets: 
- name: default-token-uudge 
imagePullSecrets: 
- name: myregistrykey 
$ kubectl replace serviceaccount default -f ./sa.yaml 
serviceaccounts/default 


现在 ， 所 有 当前 namespace 中 新 创建 的 pod 的 spec 中 都 会 增加 如 下 内 容 : 


spec: 
imagePullSecrets: 
- name: myregistrykey 


[t 


考 


https://kubernetes.io/docs/tasks/configure-pod-container/configure-service- 


account/ 
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RBAC 一 一 基于 角色 的 访问 控制 


以 下 内 容 是 xingzhou 对 kubernetes 官方 文档 的 翻译 ， 原 文 地 址 
https://k8smeetup.github.io/docs/admin/authorization/rbac/ 


基于 角色 的 访问 控制 (Role-Based Access Control, FP"RBAC") 使 
用 ”rbac.authorization.k8s.io” API Group 实现 授权 决策 ， 人 允许 管 理 员 通过 
Kubernetes API 动 态 配置 策略 。 


截至 Kubernetes 1.6，RBAC 模 式 处 于 beta 版 本 。 


要 启用 RBAC， 请 使 用 --authorization-mode=RBAC Æ #API Server ° 


API 概 述 


本 节 将 介绍 RBAC API 所 定义 的 四 种 顶级 类 型 。 用 户 可 以 像 使 用 其 他 Kubernetes 
API 资 源 一 样 (例如 通过 kubectl 、API 调 用 等 ) 与 这 些 资 源 进 行 交互 。 例 如 ， 命 
令 kubectl create -f (resource).yml 可 以 被 用 于 以 下 所 有 的 例子 ， 当 然 ， 
读者 在 尝试 前 可 能 需要 先 阅读 以 下 相关 章节 的 内 容 。 


Role 5 ClusterRole 


在 RBAC API 中 ， 一 个 角色 包含 了 一 套 表 示 一 组 权限 的 规则 。 权限 以 纯粹 的 累加 形 
RRR (没有 ”否定 ”的 规则 ) 。 角色 可 以 由 命名 空间 (namespace) 内 的 Role 对 
象 定义 ， 而 整个 Kubernetes 集 群 范围 内 有 效 的 角色 则 通过 ClusterRole TR 
现 。 


一 个 Role 对 象 只 能 用 于 授予 对 某 一 单一 命名 空间 中 资源 的 访问 权限 。 以 下 示例 
描述 了 ”default" 命 名 空间 中 的 一 个 Role 对 象 的 定义 ， 用 于 授予 对 pod 的 读 访问 权 
限 : 


kind: Role 
apiVersion: rbac.authorization.k8s.io/vibeta1 
metadata: 
namespace: default 
name: pod-reader 
rules: 
- apiGroups: [""] # 空 字符 串 "" 表 明 使 用 core API group 
resources: ["pods"] 
verbs: ["get", "watch", "list"] 


ClusterRole 对 象 可 以 授予 与 Role 对 象 相同 的 权限 ， 但 由 于 它们 属于 集群 范围 
对 象 ， 也 可 以 使 用 它们 授予 对 以 下 几 种 资源 的 访问 权限 : 


e 集群 范围 资源 (例如 节点 ， 即 node ) 
e 非 资 源 类 型 endpoint (例如 "healthz”) 
e 跨 所 有 命名 空间 的 命名 空间 范围 资源 (例如 pod， 需 要 运行 命令 kubectl get 
pods --all-namespaces 来 查询 集群 中 所 有 的 pod ) 
下 面 示例 中 的 clusterRole 定义 可 用 于 授予 用 户 对 某 一 特定 命名 空间 ， 或 者 所 有 
命名 空间 中 的 secret (取决 于 其 绑 定 方式 ) 的 读 访 问 权 限 : 


kind: ClusterRole 
apiVersion: rbac.authorization.k8s.io/vibeta1 


metadata: 
# &FClusterRolex ##¥ UHR PDA CRX EX L"namespace"FK 
name: secret-reader 

rules: 


- apiGroups: [""] 
resources: ["secrets"] 
verbs: ["get", "watch", "list"] 


RoleBinding 4 ClusterRoleBinding 


角色 绑 定 将 一 个 角色 中 定义 的 各 种 权限 授予 一 个 或 者 一 组 用 户 。 角色 绑 定 包含 了 一 
组 相关 主体 ( 即 subject, 包括 用 户 一 “User、 用 户 组 一 Group、 或 者 服务 账户 

一 Service Account) 以 及 对 被 授予 角色 的 引用 。 在 命名 空间 中 可 以 通 

过 RoleBinding 对 象 授 予 权 限 ， 而 集群 范围 的 权限 授予 则 通 

过 ClusterRoleBinding 对 象 完 成 。 





RoleBinding 可 以 引用 在 同一 命名 FE om. 
的 RoleBinding “%##"default’*? 4 "€ lal P 3$"pod-reader" 角色 授予 用 户 "jane”。 
这 一 授权 将 允许 用 户 E 命名 空间 中 读 取 pod 。 


A 以 下 角色 绑 定 定义 将 允许 用 户 "7ane" 从 "aefauIty" 命 名 空间 中 读 取 Dog 
kind: RoleBinding 
apiVersion: rbac.authorization.k8s.io/vibeta1 
metadata: 

name: read-pods 

namespace: default 
subjects: 
- kind: User 

name: jane 

apiGroup: rbac.authorization.k8s.io 
roleRef: 

kind: Role 

name: pod-reader 

apiGroup: rbac.authorization.k8s.io 


RoleBinding 对 象 也 可 以 引用 一 个 ClusterRole 对 象 用 于 在 RoleBinding PT 
在 的 命名 空间 内 授予 用 户 对 所 引用 的 clusterRole 中 定义 的 命名 空间 资源 的 访问 
权限 。 这 一 点 允许 管理 员 在 整个 集群 范围 内 首先 定义 一 组 通用 的 角色 ， 然 后 再 在 不 
同 的 命名 空间 中 复 用 这 些 角色 。 


例如 ， 尽 管 下 面 示例 中 的 RoleBinding 引用 的 是 一 个 ClusterRole 对 象 ， 但 是 
用 户 "dave”( 即 角色 绑 定 主体 ) 还 是 只 能 读 取 ”development 命名 空间 中 的 
secret (Ff RoleBinding 所 在 的 命名 空间 ) © 


A VT fe AHA P "dave" "development" 4 "Rv 4 secret 
kind: RoleBinding 
apiVersion: rbac.authorization.k8s.io/vibeta1 
metadata: 
name: read-secrets 
namespace: development # 这 里 表明 仅 授 权 读 取 "development "命名 空间 中 
的 资源 
subjects: 
- kind: User 


name: dave 

apiGroup: rbac.authorization.k8s.io 
roleRef : 

kind: ClusterRole 

name: secret-reader 

apiGroup: rbac.authorization.k8s.io 


最 后 ， 可 以 使 用 clusterRoleBinding 在 集群 级 别 和 所 有 命名 空间 中 授予 权限 。 
下 面 示例 中 所 定义 的 ClusterRoleBinding 允许 在 用 户 组 ”manager” 中 的 任何 用 
户 都 可 以 读 取 集 群 中 任何 命名 空间 中 的 secret 。 


# VAF “ClusterRoleBinding ` 对象 允许 在 用 户 组 "nanagery" 中 的 任何 用 户 都 可 以 读 
取 集 群 中 任何 命名 空间 中 的 Secret 
kind: ClusterRoleBinding 
apiVersion: rbac.authorization.k8s.io/vibeta1 
metadata: 

name: read-secrets-global 
subjects: 
- kind: Group 

name: manager 

apiGroup: rbac.authorization.k8s.io 
roleRef : 

kind: ClusterRole 

name: secret-reader 

apiGroup: rbac.authorization.k8s.io 


对 资源 的 引用 


大 多 数 资源 由 代表 其 名 字 的 字符 串 表 示 ， 例 如 "pods”， 就 像 它 们 出 现在 相关 API 
endpoint 的 URL 中 一 样 。 然 而 ， 有 一 些 Kubernetes API 还 包含 了 " 子 资 源 "， 比 如 
pod 的 logs。 在 Kubernetes 中 ，pod logs endpoint 的 URL 格 式 为 : 


GET /api/vi/namespaces/{namespace}/pods/{name}/log 


在 这 种 情况 下 ，”pods” 是 命名 空间 资源 ， 而 "log” 是 pods 的 子 资源 。 为 了 在 RBAC 角 
色 中 表示 出 这 一 点 ， 我 们 需要 使 用 斜 线 来 划分 资源 与 子 资源 。 如 果 需 要 角色 绑 定 主 
体 读 取 pods 以 及 pod log， 您 需要 定义 以 下 角色 : 


kind: Role 
apiVersion: rbac.authorization.k8s.io/vibeta1 
metadata: 
namespace: default 
name: pod-and-pod-logs-reader 
rules: 
- apiGroups: [""] 
resources: ["pods", "pods/log" ] 
verbs: ["get", "list"] 


通过 resourceNames 列表 ， 和 角色 可 以 针对 不 同 种 类 的 请 求 根据 资源 名 引用 资源 实 
例 。 当 指定 了 resourceNames 列表 时 ， 不 同 动 作 种 类 的 请 求 的 权限 ， 如 使 

用 ”get”、”delete”、"update” 以 及 ”patch” 等 动词 的 请 求 ， 将 被 限定 到 资源 列表 中 所 包 
人 钨 的 资源 实例 上 。 例如 ， 如 果 需 要 限定 一 个 角色 绑 定 主体 只 能 "get" 或 者 "update" 一 
个 configmap 时 ， 您 可 以 定义 以 下 角色 : 


kind: Role 
apiVersion: rbac.authorization.k8s.io/vibeta1 
metadata: 
namespace: default 
name: configmap-updater 
rules: 
- apiGroups: [""] 
resources: ["configmap"] 
resourceNames: ["my-configmap"] 
verbs: ["update", "get"] 


值得 注意 的 是 ， 如 果 设 置 了 resourceNames ， 则 请 求 所 使 用 的 动词 不 能 是 list、 
watch、create 或 者 deletecollection。 由 于 资源 名 不 会 出 现在 create、list、watch 和 
deletecollection 等 API 请 求 的 URL 中 ， 所 以 这 些 请 求 动词 不 会 被 设置 

了 resourceNames 的 规则 所 允许 ， 因 为 规则 中 的 resourceNames 部 分 不 会 匹配 
这 些 请 求 。 


一 些 角色 定义 的 例子 
在 以 下 示例 中 ， 我 们 仅 截 取 展 示 了 rules 部 分 的 定义 。 


允许 读 取 core API Group 中 定义 的 资源 "pods”: 


rules: 
- apiGroups: [""] 
resources: ["pods"] 
verbs: ["get", “list™, "watch"] 


允许 读 写 在 "extensions" 和 "apps” API Group 中 定义 的 "deployments”: 


rules: 
- apiGroups: ["extensions", "apps"] 

resources: ["deployments"] 

verbs: ["get", "list", "watch", "create", "update", "patch", " 
delete"] 


ATF RR pods” VUE i 5 "jobs" : 


rules: 

- apiGroups: [""] 

resources: ["pods"] 

verbs: ["get", "list", "watch"] 
apiGroups: ["batch", "extensions"] 
resources: ["jobs"] 


verbs: ["get", "list", "watch", "create", "update", "patch", " 
delete"] 


允许 读 取 一 个 名 为 "my-config” 的 configMap 实例 (需要 将 其 通 
过 RoleBinding 绑 定 从 而 限制 针对 某 一 个 命名 空间 中 定义 的 一 个 ConfigMap X 
例 的 访问 ) 


rules: 

- apiGroups: [""] 
resources: ["configmaps" ] 
resourceNames: ["my-config" ] 
verbs: ["get"] 


允许 读 取 core API Group 中 的 "nodes” 资 源 (由 于 Node 是 集群 级 别 资源 ， 所 以 
此 clusterRole 定义 需要 与 一 个 clusterRoleBinding 绑 定 才能 有 效 ) 


rules: 
- apiGroups: [""] 
resources: ["nodes"] 
verbs: ["get", "list", "watch"] 


允许 对 非 资源 endpoint healthz" 及 其 所 有 子路 径 的 "GET" 和 "POST" 请 求 
(此 ClusterRole 定义 需要 与 一 个 ClusterRoleBinding 绑 定 才能 有 效 ) 


rules: 
- nonResourceURLs: ["/healthz", "/healthz/*"] # 在 非 资 源 URL 中 ，'*! 
代表 后 级 通配符 


verbs: ["get", "post"] 


xt £5 EA EK (Subject) 的 引用 


RoleBinding 或 者 ClusterRoleBinding 34 f GAS A &9px EK 
(Subject) 。 角色 绑 定 主体 可 以 是 用 户 组 (Group) 、 用 户 (User) 或 者 服务 账 
P (Service Accounts) ° 


用 户 由 字符 串 表 示 。 可 以 是 纯粹 的 用 户 名 ， 例 如 "alice”、 电 子 邮件 风格 的 名 字 ， 如 
“bob@example.com” 或 者 是 用 字符 串 表 示 的 数字 id。 由 Kubernetes 管 理 员 配 置 认 
证 模块 以 产生 所 需 格 式 的 用 户 名 。 对 于 用 户 名 ，RBAC 授 权 系 统 不 要 求 任 何 特定 的 
格式 。 然 而 ， 前 级 system: 是 为 Kubernetes 系 统 使 用 而 保留 的 ， 所 以 管理 员 应 该 
确保 用 户 名 不 会 意外 地 和 包含 这 个 前 级 。 


Kubernetes 中 的 用 户 组 信息 由 授权 模块 提供 。 用 户 组 与 用 户 一 样 由 字符 串 表 示 。 
Kubernetes 对 用 户 组 字符 串 没有 格式 要 求 ， 但 前 级 system: 同样 是 被 系统 保留 
的 。 


服务 账户 拥有 包含 system:serviceaccount: 前 级 的 用 户 名 ， 并 属于 拥 


有 system:serviceaccounts: 前 级 的 用 户 组 。 


角色 绑 定 的 一 些 例子 
以 下 示例 中 ， 仅 截取 展示 了 RoleBinding 的 subjects 字段 。 


一 个 名 为 "alice@example.com” 的 用 户 : 


subjects: 
- kind: User 
name: "alice@example.com" 
apiGroup: rbac.authorization.k8s.io 


一 个 名 为 "frontend-admins” 的 用 户 组 : 


subjects: 
- kind: Group 
name: "frontend-admins" 
apiGroup: rbac.authorization.k8s.io 


kube-system 命 名 空间 中 的 默认 服务 账户 : 


Subjects : 

- kind: ServiceAccount 
name: default 
namespace: kube-system 


名 为 "qa" 命 名 室 间 中 的 所 有 服务 账户 : 


Subjects : 

- kind: Group 
name: system:serviceaccounts:qa 
apiGroup: rbac.authorization.k8s 


在 集群 中 的 所 有 服务 账户 : 


Subjects : 
- kind: Group 
name: system:serviceaccounts 


apiGroup: rbac.authorization.k8s. 


所 有 认证 过 的 用 户 (version 1.5+) 


Subjects : 

- kind: Group 
name: system:authenticated 
apiGroup: rbac.authorization.k8s 


所 有 未 认证 的 用 户 (version 1.5*) 


Subjects : 

- kind: Group 
name: system:unauthenticated 
apiGroup: rbac.authorization.k8s 


PRA RIP (version 1.5*) 


subjects: 
- kind: Group 
name: system:authenticated 


apiGroup: rbac.authorization.k8s. 


- kind: Group 
name: system:unauthenticated 
apiGroup: rbac.authorization.k8s 


默认 角色 与 默认 角色 绑 定 


.io 


io 


.io 


.io 


io 


.io 


API Server 会 创建 一 组 默认 的 ClusterRole 和 ClusterRoleBinding 对 象 。 这 
些 默 认 对 象 中 有 许多 包含 system: 前 级 ， 表 明 这 些 资源 由 Kubernetes 基 础 组 件 ” 拥 
有 ”。 对 这 些 资 源 的 修改 可 能 导致 非 功能 性 集群 (non-functional cluster) 。 一 个 例 
X system:node ClusterRole 对 象 。 这 个 角色 定义 了 kubelets 的 权限 。 如 果 这 
个 角色 被 修改 ， 可 能 会 导致 Kubelets 无 法 正常 工作 。 


所 有 默认 的 ClusterRole 和 ClusterRoleBinding 对 象 都 会 被 标记 
为 kubernetes.io/bootstrapping-rbac-defaults ° 


自动 更 新 


每 次 启动 时 ，API Server 都 会 更 新 默认 ClusterRole 所 缺乏 的 各 种 权限 ， 并 更 新 默认 
ClusterRoleBinding 所 缺乏 的 各 个 角色 绑 定 主体 。 这 种 自动 更 新 机 制 允许 集群 修复 
一 些 意 外 的 修改 。 由 于 权限 和 角色 绑 定 主体 在 新 的 Kubernetes 释 出 版 本 中 可 能 变 
bb， 这 也 能 够 保证 角色 和 角色 绑 定 始终 保持 是 最 新 的 。 


如 果 需 要 禁用 自动 更 新 ， 请 将 默认 ClusterRole 以 及 ClusterRoleBinding 
的 rbac.authorization.kubernetes.io/autoupdate 设置 成 为 false 。 请 注 
意 ， 缺 乏 默 认 权 限 和 角色 绑 定 主体 可 能 会 导致 非 功 能 性 集群 问题 。 


自 Kubernetes 1.6+ 起 ， 当 集群 RBAC 授 权 器 (RBAC Authorizer) 处 于 开启 状态 
时 ， 可 以 启用 自动 更 新 功能 . 


发 现 类 角色 


默认 ClusterRole 默认 ClusterRoleBinding 描述 
> > UchocEiqu 
system:basic- system:authenticated and 允许 用 户 只 读 访问 


user system:unauthenticatedgroups ie 自己 的 基本 信 


允许 只 读 访问 API 
discovery 
endpoints, 用 于 在 
API 级 别 进行 发 现 和 
协商 。 


system:authenticated and 


system:discovery system:unauthenticatedgroups 


面向 用 户 的 角色 


一 些 默 认 角 色 并 不 包含 system: AWA 
级 用 户 角色 ( cluster-admin ) 


' 它们 是 面向 用 户 的 角色 。 这 些 角色 包含 超 
> FP & Æ f| ClusterRoleBinding 


( cluster- 


status ) 在 集群 范围 内 授权 的 角色 ， 以 及 那些 使 用 
RoleBinding ( admin 、edit 和 view ) 在 特定 命名 空间 中 授权 的 角色 。 


默认 默认 
ClusterRole ClusterRoleBinding 
cluster- system:masters 
admin group 
admin None 
edit None 
view None 


Core Component Roles 


核心 组 件 角色 


描述 


超级 用 户 权 限 ， 允 许 对 任何 资源 执行 
任何 操作 。 在 ClusterRoleBinding 中 
使 用 时 ， 可 以 完全 控制 集群 和 所 有 命 
名 空间 中 的 所 有 资源 。 

在 RoleBinding 中 使 用 时 ， 可 以 完全 控 
制 RoleBinding 所 在 命名 空间 中 的 所 有 
资源 ， 包 括 命 名 空间 自己 。 


管理 员 权 限 ， 利 用 RoleBinding 在 某 一 
命名 空间 内 部 授予 。 在 RoleBinding 
中 使 用 时 ， 人 允许 针对 命名 空间 内 大 部 
分 资源 的 读 写 访 问 ， 包 括 在 命名 空间 
内 创建 角色 与 角色 绑 定 的 能 力 。 但 不 
允许 对 资源 配额 (resource quota) 或 
者 命名 空间 本 身 的 写 访 问 。 


允许 对 某 一 个 命名 空间 内 大 部 分 对 旬 
的 读 写 访 问 ， 但 不 多 许 查 看 或 者 修改 
角色 或 者 角色 绑 定 。 


允许 对 某 一 个 命名 空间 内 大 部 分 对 象 
的 只 读 访 问 。 不 允许 查看 角色 或 者 角 
色 绑 定 。 由 于 可 扩散 性 等 原因 ， 不 允 
许 查 看 secret 资 源 。 


默认 
ClusterRole 


system:kube- 
scheduler 


system:kube- 
controller- 
manager 


system:node 


system:node- 
proxier 


默认 
ClusterRoleBinding 


system:kube- 
scheduler user 


system:kube- 
controller-manager 
user 


system:nodes 
group (deprecated in 
1.7) 


system:kube-proxy 
user 


其 它 组 件 角 色 


描述 


允许 访问 kube-scheduler 组 件 所 需要 
的 资源 。 


允许 访问 kube-controller-manager 组 

件 所 需要 的 资源 。 单个 控制 循环 所 

需要 的 权限 请 参阅 控制 器 
(controller) 角色 . 


允许 对 kubelet 组 件 所 需要 的 资源 的 
访问 ， 包 括 读 取 所 有 Secret 和 对 所 有 
pod 的 写 访 问 。 É Kubernetes 1.7 开 
始 , 相 比较 于 这 个 角色 ， 更 推荐 使 

用 Node authorizer 以 及 
NodeRestriction admission plugin ， 
并 允许 根据 调度 运行 在 节点 上 的 pod 
授予 kubelets API 访 问 的 权限 。 自 
Kubernetes 1.7 开 始 ， 当 局 

用 Node 授权 模式 时 ， 

对 system:nodes J] P AA FB xe d 
不 会 被 自动 创建 。 


允许 对 kube-proxy 组 件 所 需要 资源 的 
访问 。 


默认 


ClusterRoleBinding 描述 


默认 ClusterRole 
允许 委托 认证 和 授权 检查 。 通 

None 常 由 附加 API Server 用 于 统一 
认证 和 授权 。 


system:auth- 
delegator 


system:heapster None Heapster 组 件 的 角色 。 


system:kube- 


- 28 £F t o 
aggregator NORG kube-aggregator 组 件 的 角色 


kube-dns service 
system:kube-dns account in the kube- kube-dns 组 件 的 角色 。 


systemnamespace 
允许 对 执行 Kubelet TLS 4] + 
system:node- Nene (Kubelet TLS 
bootstrapper bootstrapping) 所 需要 资源 的 
访问 . 
: 2g 4-8 
system:node None node-problem-detector 22 fF 49 


problem-detector 角色 。 


允许 对 大 部 分 动态 存储 卷 创建 
组 件 (dynamic volume 
provisioner) 所 需要 资源 的 访 
LE 


system:persistent- 
volume- None 
provisioner 


控制 器 (Controller) 角色 


Kubernetes controller manager 负 责 运 行 核心 控制 循环 。 当 使 用 --use-service- 
account-credentials 选项 运行 controller manager 时 ， 每 个 控制 循环 都 将 使 用 单 
独 的 服务 账户 启动 。 而 每 个 控制 循环 都 存在 对 应 的 角色 ， 前 级 名 

为 system:controller: 。 如 果 不 使 用 --use-service-account- 
credentials 选项 时 ，controller manager 将 会 使 用 自己 的 凭证 运行 所 有 控制 循 
环 ， 而 这 些 和 凭证 必须 被 授予 相关 的 角色 。 这 些 角色 和 包括: 


e system:controller:attachdetach-controller 
e system:controller:certificate-controller 

e system:controller:cronjob-controller 

e system:controller:daemon-set-controller 

e system:controller:deployment-controller 

e system:controller:disruption-controller 

e system:controller:endpoint-controller 


e system:controller:generic-garbage-collector 
e system:controller:horizontal-pod-autoscaler 
e system:controller:job-controller 

e system:controller:namespace-controller 

e system:controller:node-controller 

e system:controller:persistent-volume-binder 

e system:controller:pod-garbage-collector 

e system:controller:replicaset-controller 

e system:controller:replication-controller 

e system:controller:resourcequota-controller 

e system:controller:route-controller 

e system:controller:service-account-controller 
e system:controller:service-controller 

e system:controller:statefulset-controller 

e system:controller:ttl-controller 


初始 化 与 预防 权限 升级 


RBAC API 会 阻止 用 户 通过 编辑 角色 或 者 角色 绑 定 来 升级 权限 。 由 于 这 一 点 是 在 
API 级 别 实现 的 ， 所 以 在 RBAC 授 权 器 (RBAC authorizer) 未 启用 的 状态 下 依然 可 
以 正常 工作 。 


用 户 只 有 在 拥有 了 角色 所 包含 的 所 有 权限 的 条 件 下 才能 创建 更 新 一 个 角色 ， 这 些 
操作 还 必须 在 角色 所 处 的 相同 范围 内 进行 (对 于 ClusterRole 来 说 是 集群 范围 ， 
对 于 Role 来 说 是 在 与 角色 相同 的 命名 空间 或 者 集群 范围 ) 。 例 如 ， 如 果 用 

户 ”User-1” 没 有 权限 读 取 集 群 范围 内 的 secret 列 表 ， 那 么 他 也 不 能 创建 包含 这 种 权限 
的 ClusterRole 。 为 了 能 够 让 用 户 创建 更 新 角色 ， 需 要 : 


1. 授予 用 户 一 个 角色 以 允许 他 们 根据 需要 创建 更 新 Role 或 
者 ClusterRole 4% ° 

2. 授予 用 户 一 个 角色 包含 他 们 在 Role 或 者 ClusterRole 中 所 能 够 设置 的 所 有 
权限 。 如 果 用 户 尝试 创建 或 者 修改 Role 或 者 ClusterRole 以 设置 那些 他 们 
未 被 授权 的 权限 时 ， 这 些 API 请 求 将 被 禁止 。 


用 户 只 有 在 拥有 所 引用 的 角色 中 包含 的 所 有 权限 时 才 可 以 创建 更 新 角色 绑 定 (这 
些 操作 也 必须 在 角色 绑 定 所 处 的 相同 范围 内 进行 ) 或 者 用 户 被 明确 授权 可 以 在 所 引 
用 的 角色 上 执行 绑 定 操作 。 例如 ， 如 果 用 户 "user- 人 没有 权限 读 取 集 群 范围 内 的 


secret 列 表 ， 那 么 他 将 不 能 创建 ClusterRole 来 引用 那些 授予 了 此 项 权限 的 角 
色 。 为 了 能 够 让 用 户 创建 A 更 新 角色 绑 定 ， 需 要 : 


1. 授予 用 户 一 个 角色 以 允许 他 们 根据 需要 创建 更 新 RoleBinding 或 
者 ClusterRoleBinding 对 象 。 
2. 授予 用 户 绑 定 某 一 特定 角色 所 需要 的 权限 : 
o 隐 式 地 ， 通 过 授予 用 户 所 有 所 引用 的 角色 中 所 包含 的 权限 
o 显 式 地 ， 通 过 授予 用 户 在 特定 Role (或 者 ClusterRole) 对 象 上 执 
行 bind 操作 的 权限 


例如 ， 下 面 例子 中 的 ClusterRole 和 RoleBinding 将 允许 用 户 "User-1” 授 予 其 它 用 
户 "User-1-namespace” 命 名 空间 内 的 admin ^ edit 和 view 4/8 EF A EA 
& o 


apiVersion: rbac.authorization.k8s.io/vibeta1 
kind: ClusterRole 
metadata: 
name: role-grantor 
rules: 
- apiGroups: ["rbac.authorization.k8s.io"] 
resources: ["rolebindings"] 
verbs: ["create"] 
apiGroups: ["rbac.authorization.k8s.io"] 
resources: ["clusterroles"] 
verbs: ["bind"] 
resourceNames: ["admin", "edit", "view" ] 
apiVersion: rbac.authorization.k8s.io/vibeta1 
kind: RoleBinding 
metadata: 
name: role-grantor-binding 
namespace: user-1-namespace 
roleRef : 
apiGroup: rbac.authorization.k8s.io 
kind: ClusterRole 
name: role-grantor 
subjects: 
- apiGroup: rbac.authorization.k8s.io 
kind: User 
name: user-1 
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初始 化 初始 角色 和 角色 绑 定 时 需要 : 


e 使 用 包含 system: masters 用 户 组 的 赁 证 ， 该 用 户 组 通过 默认 绑 定 绑 定 


到 cluster-admin son 角色 。 
e 如 果 您 的 API Server 在 运行 时 局 用 了 非 安 全 端口 ( --insecure-port ) ， 您 
也 可 以 通过 这 个 没有 施 USA irene 角色 或 者 角色 绑 定 请 求 。 


一 些 命令 行 工具 
有 两 个 kubectl 命令 可 以 用 于 在 命名 空间 内 或 者 整个 集群 内 授予 角色 。 


kubectl create rolebinding 


在 某 一 特定 命名 空间 内 授予 Role AX ClusterRole 。 示 例如 下 
e 在 名 为 "9cme” 的 命名 空间 中 将 admin ClusterRole 授予 用 户 ”bob”: 


kubectl create rolebinding bob-admin-binding -- 
clusterrole=admin --user=bob --namespace=acme 


e 在 名 为 "acme” 的 命名 空间 中 将 view ClusterRole 授予 服务 账户 ”myapp”: 


kubectl create rolebinding myapp-view-binding -- 
clusterrole=view --serviceaccount=acme:myapp --namespace=acme 


kubectl create clusterrolebinding 


在 整个 集群 中 授予 clusterRole ， 包 括 所 有 命名 空间 。 示 例如 下 : 
e 在 整个 集群 范围 内 将 cluster-admin ClusterRole 授予 用 户 *root”: 


kubectl create clusterrolebinding root-cluster-admin-binding -- 
clusterrole=cluster-admin --user=root 


e 在 整个 集群 范围 内 将 system:node ClusterRole 4% f M P "kubelet” : 


kubectl create clusterrolebinding kubelet-node-binding -- 
clusterrole=system:node --user=kubelet 


e 在 整个 集群 范围 内 将 view  ClusterRole 授予 命名 空间 ”acme” 内 的 服务 账 
户 ” myapp” : 


kubectl create clusterrolebinding myapp-view-binding -- 
clusterrole-view --serviceaccount-acme:myapp 


请 参阅 CLI 帮 助 文档 以 获得 上 述 命令 的 详细 用 法 


服务 账户 (Service Account) 权限 


默认 的 RBAC 策 略 将 授予 控制 平面 组 件 (control-plane component) 、 节 点 
(node) 和 控制 器 (controller) 一 组 范围 受 限 的 权限 ， 但 对 于 "kube-system" 命 名 
空间 以 外 的 服务 账户 ， 则 不 授予 任何 权限 (超出 授予 所 有 认证 用 户 的 发 现 权 限 ) 。 


好 的 安全 性 ， 但 需要 更 多 精力 管理 。 更 粗 粒度 的 授权 可 能 授予 服务 账号 不 需要 的 
API 访 问 权 限 (甚至 导致 潜在 授权 扩散 ) ， 但 更 易于 管理 。 


从 最 安全 到 最 不 安全 可 以 排序 以 下 方法 : 
1. 对 某 一 特定 应 用 程序 的 服务 账户 授予 角色 《最 佳 实践 ) 
要 求 应 用 程序 在 其 pod 规 范 (pod spec) 中 指定 serviceAccountName 字段 ， 


并 且 要 创建 相应 服务 账户 (例如 通过 API、 应 用 程序 清单 或 者 命令 kubectl 


create serviceaccount 4) » 


例如 ， 在 ”my-namespace” 命 名 空间 中 授予 服务 账户 *”my-sa" 只 读 权 限 : 


kubectl create rolebinding my-sa-view \ 
--clusterrole=view \ 
--serviceaccount=my-namespace:my-sa \ 
- -namespace=my -namespace 


2. 在 某 一 命名 空间 中 授予 "default" 服 务 账号 一 个 角色 


如 果 一 个 应 用 程序 没有 在 其 pod 规 范 中 指定 serviceAccountName ， 它 将 默认 
使 用 "default" 服 务 账 号 。 


注意 : 授予 "default" 服 务 账 号 的 权限 将 可 用 于 命名 空间 内 任何 没有 指 


Æ serviceAccountName pod ° 


下 面 的 例子 将 在 "my-namespace" 命 名 空间 内 授予 "default" 服 务 账 号 只 读 权 限 : 


kubectl create rolebinding default-view \ 
--clusterrole=view \ 
--serviceaccount=my-namespace:default \ 
- -namespace=my -namespace 


目前 ， 许 多 加 载 项 (addon) % A”kube-system’* 4 # lal P "default" IR 2- TK 
户 运行 。 要 允许 这 些 加 载 项 使 用 超级 用 户 访 问 权 限 ， 请 将 cluster-admin 权 限 授 
予 "kube-system" 命 名 空间 中 的 "default" 服 务 帐 户 。 注 意 : 启用 上 述 操 作 意 味 
着 "kube-system" 命 名 空间 将 包含 允许 超级 用 户 访问 API| 的 秘 钥 。 


kubectl create clusterrolebinding add-on-cluster-admin \ 
--clusterrole=cluster-admin \ 
--serviceaccount=kube-system:default 


. 为 命名 空间 中 所 有 的 服务 账号 授予 角色 


如 果 您 希望 命名 空间 内 的 所 有 应 用 程序 都 拥有 同一 个 角色 ， 无 论 它们 使 用 什么 
服务 账户 ， 您 可 以 为 该 命名 空间 的 服务 账户 用 户 组 授予 角色 。 


下 面 的 例子 将 授予 ?my-namespace" 命 名 空间 中 的 所 有 服务 账户 只 读 权 限 : 


kubectl create rolebinding serviceaccounts-view \ 
--clusterrole-view \ 
--group=system:serviceaccounts:my-namespace \ 
- -namespace=my -namespace 


.对 集群 范围 内 的 所 有 服务 账户 授予 一 个 受 限 角色 (不 鼓励 ) 

如 果 您 不 想 管理 每 个 命名 空间 的 权限 ， 则 可 以 将 集群 范围 角色 授予 所 有 服务 帐 
户 o 

下 面 的 例子 将 所 有 命名 空间 中 的 只 读 权 限 授 予 集群 中 的 所 有 服务 账户 : 


kubectl create clusterrolebinding serviceaccounts-view \ 
--clusterrole-view \ 
--group=system:serviceaccounts 


.授予 超级 用 户 访问 权限 给 集群 范围 内 的 所 有 服务 帐户 (强烈 不 鼓励 ) 
如 果 您 根本 不 关心 权限 分 块 ， 您 可 以 对 所 有 服务 账户 授予 超级 用 户 访 问 权 限 。 


警告 : 这 种 做 法 将 允许 任何 具有 读 取 权 限 的 用 户 访问 secret 或 者 通过 创建 一 个 
容器 的 方式 来 访问 超级 用 户 的 凭据 。 


kubectl create clusterrolebinding serviceaccounts-cluster-ad 
min \ 
--clusterrole-cluster-admin \ 
--group=system:serviceaccounts 


从 版 本 1.5 升 级 


在 Kubernetes 1.6 之 前 ， 许 多 部 署 使 用 非常 宽泛 的 ABAC 策 略 ， 包 括 授 予 对 所 有 服 
务 帐 户 的 完整 API 访 问 权 限 © 


默认 的 RBAC 策 略 将 授予 控制 平面 组 件 (control-plane components) 、 节 点 
(nodes) 和 控制 器 (controller) 一 组 范围 受 限 的 权限 ， 但 对 于 ”kube-system" 命 
名 空间 以 外 的 服务 账户 ， 则 不 授予 任何 权限 〈 超 出 授予 所 有 认证 用 户 的 发 现 权 
FR) 。 


虽然 安全 性 更 高 ， 但 这 可 能 会 影响 到 期 望 自 动 接 收 API 权 限 的 现 有 工作 负载 。 以 下 
是 管理 此 转换 的 两 种 方法 : 

并 行 授 权 器 (authorizer ) 

同时 运行 RBAC 和 ABAC 授 权 器 ， 并 包括 旧版 ABAC 策 略 : 


--authorization-mode=RBAC,ABAC --authorization-policy-file=mypol 
icy.jsonl 


RBAC 授 权 器 将 尝试 首先 授权 请 求 。 如 果 RBAC 授 权 器 拒绝 API 请 求 ， 则 ABAC 授 权 
器 将 被 运行 。 这 意味 着 RBAC 策 略 或 者 ABAC 策 略 所 允许 的 任何 请 求 都 是 可 通过 
的 。 


当 以 日 志 级 别 为 2 或 更 高 ( --v = 2 ) 运行 时 ， 您 可 以 在 API Server 日 志 中 看 到 
RBAC 拒 绝 请 求 信息 (以 RBAC DENY: AAA) 。 您 可 以 使 用 该 信息 来 确定 哪些 
角色 需要 授予 哪些 用 户 ， 用 户 组 或 服务 帐户 。 一 旦 授予 服务 帐户 角色 ， 并 且 服 务 器 
日 志 中 没有 RBAC 拒 绝 消息 的 工作 负载 正在 运行 ， 您 可 以 删除 ABAC 授 权 器 。 


宽泛 的 RBAC 权 限 


您 可 以 使 用 RBAC 角 色 绑 定 来 复制 一 个 宽泛 的 策略 。 


警告 : 以 下 政策 略 允 许 所 有 服务 帐户 作为 集群 管理 员 。 和 运行 在 容器 中 的 任何 应 用 程 
序 都 会 自动 接收 服务 帐户 凭据 ， 并 且 可 以 对 API 执 行 任何 操作 ， 包 括 查 看 secret 和 
修改 权限 。 因此 ， 并 不 推荐 使 用 这 种 策略 。 


kubectl create clusterrolebinding permissive-binding \ 
--clusterrole=cluster-admin \ 
--user=admin \ 
--user=kubelet \ 
--group=system: serviceaccounts 
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Network Policy 


网 络 策略 说 明 一 组 Pod 之 间 是 如 何 被 允许 互相 通信 ， 以 及 如 何 与 其 它 网 络 
pM 于 通信 。 NetworkPolicy 资源 使 用 标签 来 选择 Pod ， 并 定义 了 一 


些 规则 ， 这 些 规 则 指明 允许 什么 流量 进入 到 选中 的 Pod Ee 
前 提 条 件 


网 络 策略 通过 网 络 插件 来 实现 ， 所 以 必须 使 用 一 种 支持 NetworkPolicy 的 网 络 
方案 —— 3E Controller 创建 的 资源 ， 是 不 起 作用 的 。 


隔离 的 与 未 隔离 的 Pod 


默认 Pod 是 未 隔离 的 ， 它 们 可 以 从 任何 的 源 接收 请 求 。 具 有 一 个 可 以 选 neha 
网 络 策略 后 ，Pod 就 会 变 成 隔离 的 。 —€ Namespace 中 配置 的 网 络 策略 能 够 选 
一 个 特定 的 Pod， 这 个 Pod 将 拒绝 任何 该 网 络 策略 不 允许 的 连接 。 entem 
中 其 它 未 被 网 络 策略 选中 的 Pod 将 继续 接收 所 有 流量 ) 


NetworkPolicy 资源 


查看 API 参 考 可 以 获取 该 资源 的 完整 定义 。 


下 面 是 一 个 NetworkPolicy 的 例子 : 


apiVersion: networking.k8s.io/vi 
kind: NetworkPolicy 
metadata: 
name: test-network-policy 
namespace: default 
spec: 
podSelector: 
matchLabels: 
role: db 
ingress: 
- from: 
- namespaceSelector: 
matchLabels: 
project: myproject 
- podSelector: 
matchLabels: 
role: frontend 
ports: 
- protocol: TCP 
port: 6379 


将 上 面 配置 POST 到 API Server 将 不 起 任何 作用 ， 除 非 选 择 的 网 络 方案 支持 网 络 
策略 。 


必 选 字段 : 像 所 有 其 它 Kubernetes 配置 一 样 ， NetworkPolicy 需要 
apiVersion ^ kind 和 metadata 这 三 个 字段 ， 关 于 如 何 使 用 配置 文件 的 基 
本 信息 ， 可 以 查看 这 里 ， 这 里 和 这 里 。 


spec: NetworkPolicy spec 具有 在 给 定 Namespace 中 定义 特定 网 络 的 全 部 信 
ao 


wo 


podSelector : 每 个 NetworkPolicy 包含 一 个 podSelector ， 它 可 以 选择 一 
组 应 用 了 网 络 策略 的 Pod。 由 于 NetworkPolicy 当前 只 支持 定义 ingress 规 
则 ， 这 个 podSelector 实际 上 为 该 策略 定义 了 一 组 “目标 Pod”。 示 例 中 的 策略 选 
择 了 标签 为 “role=db” 的 Pod » —*##) podSelector 选择 了 该 Namespace 中 
的 所 有 Pod。 


ingress : 每 个 NetworkPolicy 包含 了 一 个 白 名 单 ingress 规则 列表 。 每 个 规 
则 只 允许 能 够 匹配 上 from 和 ports 配置 段 的 流量 。 示 例 策略 包含 了 单个 规 
则 ， 它 从 这 两 个 源 中 匹配 在 单个 端口 上 的 流量 ， 第 一 个 是 通 

过 namespaceselector 指定 的 ， 第 二 个 是 通过 podSelector 指定 的 。 


因此 ， 上 面 示例 的 NetworkPolicy : 


1. Æ “default” Namespace? 隔离 了 标签 “role=db” 的 Pod (如 果 他 们 还 没有 被 
HA) 

2. 7 "default" Namespace 中 ， 允 许 任 何 具 有 “role=frontend” 的 Pod > 34} 2] 43 
签 为 “role=db” 的 Pod 的 TCP 端口 6379 

3. 允许 在 Namespace 中 任何 具有 标签 “project=myproject” 的 Pod， 连 接 到 
“default” Namespace 中 标签 为 “role=db” 的 Pod 的 TCP 端口 6379 


查看 NetworkPolicy 入 门 指南 给 出 的 更 进一步 的 例子 。 


URS 


通过 创建 一 个 可 以 选择 所 有 Pod 但 不 允许 任何 流量 的 NetworkPolicy， 你 可 以 为 一 
个 Namespace 创建 一 个 “默认 的 " 隔离 策略 ， 如 下 所 示 : 


apiVersion: networking.k8s.io/vi 
kind: NetworkPolicy 
metadata: 
name: default-deny 
spec: 
podSelector: 


这 确保 了 即使 是 没有 被 任何 NetworkPolicy 选中 的 Pod， 将 仍然 是 被 隔离 的 。 


可 选 地 ， 在 Namespace 中 ， 如 果 你 想 允 许 所 有 的 流量 进入 到 所 有 的 Pod (即使 已 
经 添加 了 某 些 策略 ， 使 一 些 Pod 被 处 理 为 “隔离 的 ") ， 你 可 以 通过 创建 一 个 策略 来 
显 式 地 指定 允许 所 有 流量 : 


apiVersion: networking.k8s.io/vi 
kind: NetworkPolicy 
metadata: 
name: allow-all 
spec: 
podSelector: 
ingress: 


m 


原文 地 址 : https://k8smeetup.github.io/docs/concepts/services- 
networking/network-policies/ 


译 者 : shirdrn 
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存储 
为 了 管理 存储 ，Kubernetes 提 供 了 Secret 用 于 管理 敏感 信息 ，ConfigMap 存 储 配 
置 ，Volume、PV、PVC、StorageClass 等 用 来 管理 存储 卷 。 
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Secret 


Secret 解 决 了 密码 、token、 密 钥 等 敏感 数据 的 配置 问题 ， 而 不 需要 把 这 些 敏感 数据 
暴露 到 镜像 或 者 Pod Spec 中 。Secret 可 以 以 Volume 或 者 环境 变量 的 方式 使 用 。 


Secret 有 三 种 类 型 : 


e Service Account : 用 来 访问 Kubernetes API， 由 Kubernetes 自 动 创 建 ， 并 且 
会 自动 挂 载 到 Pod 的 /run/secrets/kubernetes.io/serviceaccount 目录 
Y; 

e Opaque : base64 编 码 格 式 的 Secret， 用 来 存储 密码 、 密 钥 等 ; 

e kubernetes.io/dockerconfigjson : 用 来 存储 私有 docker registry 的 认证 信 
自 。 


me 


Opaque Secret 


Opaque 类 型 的 数据 是 一 个 map 类 型 ， 要 求 value 是 base64 编 码 格式 : 


$ echo -n "admin" | base64 
YWRt aw4= 
$ echo -n "1f2d1e2e67df" | base64 
MWY yZDFLMmU2N2Rm 
secrets.yml 


apiVersion: v1 

kind: Secret 

metadata: 
name: mysecret 

type: Opaque 

data: 
password: MWYyZDF1MmU2N2Rm 
username: YWRtaW4- 


接着 ， 就 可 以 创建 secret 了 : kubectl create -f secrets.yml 。 
创建 好 secret 之 后 ， 有 两 种 方式 来 使 用 它 : 


e 以 Volume 方 式 


e 以 环境 变量 方式 


将 Secret 挂 载 到 Volume 中 


apiVersion: v1 

kind: Pod 

metadata: 
labels: 

name: db 

name: db 
spec: 
volumes: 
- name: secrets 

secret: 

secretName: mysecret 
containers: 
- image: gcr.io/my_project_id/pg:v1 
name: db 

volumeMounts: 

- name: secrets 
mountPath: "/etc/secrets" 
readOnly: true 

ports: 

- name: cp 
containerPort: 5432 
hostPort: 5432 


将 Secret 导 出 到 环境 变量 中 


apiVersion: extensions/vibeta1 
kind: Deployment 
metadata: 
name: wordpress-deployment 
spec: 
replicas: 2 
strategy: 
type: RollingUpdate 
template: 
metadata: 
labels: 
app: wordpress 
visualize: "true" 
spec: 
containers: 
- name: "wordpress" 
image: "wordpress" 


ports: 
- containerPort: 80 
env: 
- name: WORDPRESS DB USER 
valueFrom: 
secretKeyRef: 


name: mysecret 
key: username 
- name: WORDPRESS DB PASSWORD 
valueFrom: 
secretKeyRef: 
name: mysecret 
key: password 


kubernetes.io/dockerconfigjson 
可 以 直接 用 kubectl 命令 来 创建 用 于 docker registry? tE fJ secret : 


$ kubectl create secret docker-registry myregistrykey --docker-s 
erver=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --doc 
ker-password-DOCKER PASSWORD --docker-email-DOCKER EMAIL 

secret "myregistrykey" created. 


也 可 以 直接 读 取 -/.docker/config.json 的 内 容 来 创建 : 


$ cat ~/.docker/config.json | base64 
$ cat > myregistrykey.yaml ««EOF 
apiVersion: vi 

kind: Secret 

metadata: 

name: myregistrykey 
data: 

.dockerconfigjson: UmVhbGx5IHJlYWxseSByZWVlZWVlZWVlZWFhYWFhYWF 
hYWwFhYWwFhYWFhYWFhYWFhYWFhYWxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGx 
sbGx5beX15eX15eX15eX15eXl5eXl5eSBsbGxsbGxsbGxsbGxsbG9vb29vb29vb29 
vb29vb29vb29vb29vb29vb25ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2d 
nZ2dnZ2dnZ2dnZ2cgYXVOaCBrZX1zCg== 
type: kubernetes.io/dockerconfigjson 
EOF 
$ kubectl create -f myregistrykey.yaml 


在 创建 Pod 的 时 候 ， 通 过 imagePullsecrets 来 引用 刚 创建 的 myregistrykey : 


apiVersion: vi 
kind: Pod 
metadata: 
name: foo 
spec: 
containers: 
- name: foo 
image: janedoe/awesomeapp: v1 
imagePullSecrets: 
- name: myregistrykey 


Service Account 


Service Account 用 来 访问 Kubernetes API， 由 Kubernetes 自 动 创建 ， 并 且 会 自动 挂 
载 到 Pod 的 /run/secrets/kubernetes.io/serviceaccount 目录 中 。 


$ kubectl run nginx --image nginx 
deployment "nginx" created 
$ kubectl get pods 


NAME READY STATUS RESTARTS AGE 
nginx -3137573019-md1u2 1/1 Running 0 13s 

$ kubectl exec nginx-3137573019-mdiu2 ls /run/secrets/kubernetes 
.10/serviceaccount 

ca.crt 

namespace 


token 


Copyright © jimmysong.io 2017-2018 all right reserved * powered by 
GitbookUpdated at 2018-05-09 14:15:47 


ConfigMap 


其 实 ConfigMap 功 能 在 Kubernetes1.2 版 本 的 时 候 就 有 了 ， 许 多 应 用 程序 会 从 配置 文 
件 、 命 令 行 参数 或 环境 变量 中 读 取 配 置信 息 。 这 些 配 置信 息 需 要 与 docker image 解 
耦 ， 你 总 不 能 每 修改 一 个 配置 就 重 做 一 个 image 吧 ? ConfigMap API 给 我 们 提供 了 
向 容器 中 注入 配置 信息 的 机 制 ，ConfigMap 可 以 被 用 来 保存 单个 属性 ， 也 可 以 用 来 
保存 整个 配置 文件 或 者 JSON 二 进 制 大 对 象 。 


ConfigMap 概 览 


ConfigMap API 资 源 用 来 保存 key-value pair 配 置 数据 ， 这 个 数据 可 以 在 pods 里 使 
用 ， 或 者 被 用 来 为 像 controller 一 样 的 系统 组 件 存储 配置 数据 。 虽 然 ConfigMap 跟 
Secrets 类 似 ， 但 是 ConfigMap 更 方便 的 处 理 不 含 敏感 信息 的 字符 串 。 注意 : 
ConfigMaps 不 是 属性 配置 文件 的 替代 品 。ConfigMaps 只 是 作为 多 个 properties 文 件 
的 引用 。 你 可 以 把 它 理解 为 Linux 系 统 中 的 /etc 目录 ， 专 门 用 来 存储 配置 文件 的 
目录 。 下 面 举 个 例子 ， 使 用 ConfigMap 配 置 来 创建 Kuberntes Volumes * ConfigMap 
中 的 每 个 data 项 都 会 成 为 一 个 新 文件 。 


kind: ConfigMap 
apiVersion: v1 
metadata: 
creationTimestamp: 2016-02-18T19:14:38Z 
name: example-config 
namespace: default 
data: 
example.property.1: hello 
example.property.2: world 
example.property.file: |- 
property.1=value-1 
property. 2=value-2 
property.3=value-3 


data 一 栏 包括 了 配置 数据 ，ConfigMap 可 以 被 用 来 保存 单个 属性 ， 也 可 以 用 来 保 
存 一 个 配置 文件 。 配置 数据 可 以 通过 很 多 种 方式 在 Pods 里 被 使 用 。ConfigMaps 可 
以 被 用 来 : 


1. 设置 环境 变量 的 值 
2. 在 容器 里 设置 命令 行 参 数 


3. 在 数据 卷 里 面 创 建 config 文 件 
用 户 和 系统 组 件 两 者 都 可 以 在 ConfigMap 里 面 存储 配置 数据 。 
其 实 不 用 看 下 面 的 文章 ， 直 接 从 kubectl create configmap -h 的 帮助 信息 中 


就 可 以 对 ConfigMap 完 竟 如 何 创建 略 知 一 二 了 。 


Examples: 
# Create a new configmap named my-config based on folder bar 
kubectl create configmap my-config --from-file=path/to/bar 


# Create a new configmap named my-config with specified keys i 
nstead of file basenames on disk 

kubectl create configmap my-config --from-file=key1=/path/to/b 
ar/filei.txt --from-file=key2=/path/to/bar/file2.txt 

# Create a new configmap named my-config with keyi=configi and 

key2-config2 

kubectl create configmap my-config --from-literal=key1=config1 

--from-literal-key2-config2 


€| 32 ConfigMaps 
可 以 使 用 该 命令 ， 用 给 定 值 、 文 件 或 目录 来 创建 ConfigMap。 


kubectl create configmap 


使 用 目录 创建 


比如 我 们 已 经 有 个 了 包含 一 些 配置 文件 ， 其 中 包含 了 我 们 想 要 设置 的 ConfigMap 的 
值 : 


$ 1s docs/user-guide/configmap/kubectl/ 
game.properties 
ui.properties 


$ cat docs/user-guide/configmap/kubectl/game.properties 
enemies-aliens 

lives-3 

enemies.cheat-true 

enemies.cheat.level-noGoodRotten 
secret.code.passphrase-UUDDLRLRBABAS 
secret.code.allowed-true 

secret.code.lives-30 


$ cat docs/user-guide/configmap/kubectl/ui.properties 
color.good-purple 

color.bad-yellow 

allow.textmode-true 

how.nice.to.look-fairlyNice 


使 用 下 面 的 命令 可 以 创建 一 个 包含 目录 中 所 有 文件 的 ConfigMap。 


$ kubectl create configmap game-config --from-file-docs/user-gui 


de/configmap/kubectl 


—from-file 指定 在 目录 下 的 所 有 文件 都 会 被 用 在 ConfigMap 里 面 创建 一 个 键 值 


对 ， 键 的 名 字 就 是 文件 名 ， 值 就 是 文件 的 内 容 。 


让 我 们 来 看 一 下 这 个 命令 创建 的 ConfigMap : 


$ kubectl describe configmaps game-config 


Name: game -config 
Namespace: default 

Labels: <none> 
Annotations: <none> 

Data 

game.properties: 158 bytes 
ui.properties: 83 bytes 


我 们 可 以 看 到 那 两 个 key 是 从 kubectl 指 定 的 目录 中 的 文件 名 。 这 些 key 的 内 容 可 
很 大 ， 所 以 在 kubectl describe 的 输出 中 ， 只 能 够 看 到 键 的 名 字 和 他 们 的 大 小 。 
果 想 要 看 到 键 的 值 的 话 ， 可 以 使 用 kubectl get 


ae, 
能 会 


如 


$ kubectl get configmaps game-config -o yaml 


我 们 以 yaml 格式 输出 配置 。 


apiVersion: vi 
data: 
game.properties: | 
enemies-aliens 
lives-3 
enemies.cheat-true 
enemies.cheat.level-noGoodRotten 
secret.code.passphrase-UUDDLRLRBABAS 
secret.code.allowed-true 
secret.code.lives-30 
ui.properties: | 
color.good-purple 
color .bad=yellow 
allow. textmode=true 
how.nice.to.look-fairlyNice 
kind: ConfigMap 
metadata: 
creationTimestamp: 2016-02-18T18:34:05Z 
name: game-config 
namespace: default 
resourceVersion: "407" 
selfLink: /api/vi/namespaces/default/configmaps/game-config 
uid: 30944725-d66e-11e5-8cd0-68f728db1985 


使 用 文件 创建 


刚才 使 用 目录 创建 的 时 候 我 们 —from-file 指定 的 是 一 个 目录 ， 只 要 指定 为 一 个 
文件 就 可 以 从 单个 文件 中 创建 ConfigMap ° 


$ kubectl create configmap game-config-2 --from-file=docs/user-g 
uide/configmap/kubectl/game. properties 


$ kubectl get configmaps game-config-2 -o yaml 


apiVersion: v1 
data: 
game-special-key: | 
enemies=aliens 
lives=3 
enemies.cheat=true 
enemies.cheat.level-noGoodRotten 
secret.code.passphrase-UUDDLRLRBABAS 
secret.code.allowed-true 
secret.code.lives-30 
kind: ConfigMap 
metadata: 
creationTimestamp: 2016-02-18T18:54:22Z 
name: game-config-3 
namespace: default 
resourceVersion: "530" 
selfLink: /api/vi1/namespaces/default/configmaps/game-config-3 
uid: 05f8da22-d671-11e5-8cd0-68f728db1985 


—from-file 这 个 参数 可 以 使 用 多 次 ， 你 可 以 使 用 两 次 分 别 指 定 上 个 实例 中 的 那 
两 个 配置 文件 ， 效 果 就 跟 指 定 整个 目录 是 一 样 的 。 


使 用 字面 值 创 建 


使 用 文字 值 创建 ， 利 用 —from-literal 参数 传递 配置 信息 ， 该 参数 可 以 使 用 多 
次 ， 格 式 如 下 5 


$ kubectl create configmap special-config --from-literal=special 
-how=very --from-literal-special.type-charm 


$ kubectl get configmaps special-config -o yaml 


apiVersion: vi 
data: 
special.how: very 
special.type: charm 
kind: ConfigMap 
metadata: 
creationTimestamp: 2016-02-18T19:14:38Z 
name: special-config 
namespace: default 
resourceVersion: "651" 
selfLink: /api/vi/namespaces/default/configmaps/special-config 
uid: dadce046-d673-11e5-8cd0-68f728db1985 


Pod ¥ 1% | ConfigMap 


使 用 ConfigMap 来 替代 环境 变量 


ConfigMap 可 以 被 用 来 卉 入 环境 变量 。 看 下 下 面 的 ConfigMap 。 


apiVersion: vi 
kind: ConfigMap 
metadata: 
name: special-config 
namespace: default 
data: 
special.how: very 
special.type: charm 


apiVersion: vi 
kind: ConfigMap 
metadata: 
name: env-config 
namespace: default 
data: 
log level: INFO 


我 们 可 以 在 Pod 中 这 样 使 用 ConfigMap : 


apiVersion: v1 
kind: Pod 
metadata: 
name: dapi-test-pod 
spec: 
containers: 
- name: test-container 
image: gcr.io/google_containers/busybox 
command: [ "/bin/sh", "-c", "env" | 
env: 
- name: SPECIAL_LEVEL_KEY 
valueFrom: 
configMapKeyRef : 
name: special-config 
key: special.how 
- name: SPECIAL_TYPE_KEY 
valueFrom: 
conf igMapKeyRef : 
name: special-config 
key: special.type 
envFrom: 
- configMapRef: 
name: env-config 
restartPolicy: Never 


这 个 Pod 运 行 后 会 输出 如 下 几 行 : 


SPECIAL LEVEL KEY-very 
SPECIAL TYPE KEY-charm 
log level-INFO 


Fl ConfigMap:X E 4 4-47 4 3 


ConfigMap 也 可 以 被 使 用 来 设置 容器 中 的 命令 或 者 参数 值 。 它 使 用 的 是 Kubernetes 
的 $(VAR_NAME) 替 换 语法 。 我 们 看 下 下 面 这 个 ConfigMap ° 


apiVersion: v1 
kind: ConfigMap 
metadata: 
name: special-config 
namespace: default 
data: 
special.how: very 
special.type: charm 


为 了 将 ConfigMap 中 的 值 注入 到 命令 行 的 参数 里 面 ， 我 们 还 要 像 前 面 那个 例子 一 样 
人 。 (其 实 这 个 东西 就 是 给 Docker 容 器 设置 环 
境 变量 ， 以 前 我 创建 镜像 的 时 候 经 常 这 么 玩 ， 通 过 docker run 的 时 候 指 定 -e 参 数 修 

改 镜 像 里 的 环境 变量 ， Ai 令 再 利用 该 $(VAR_NAME) 通 过 sed 来 

修改 配置 文件 或 者 作为 命令 行 启动 参数 。) 


apiVersion: vi 
kind: Pod 
metadata: 
name: dapi-test-pod 
spec: 
containers: 
- name: test-container 
image: gcr.io/google containers/busybox 
command: [ "/bin/sh", "-c", "echo $(SPECIAL LEVEL KEY) $(S 
PECIAL TYPE KEY)" ] 
env: 
- name: SPECIAL LEVEL KEY 
valueFrom: 
configMapKeyRef: 
name: special-config 
key: special.how 
- name: SPECIAL TYPE KEY 
valueFrom: 
configMapKeyRef: 
name: special-config 
key: special.type 
restartPolicy: Never 


very charm 


通过 数据 卷 插件 使 用 ConfigMap 


ConfigMap 也 可 以 在 数据 卷 里 面 被 使 用 。 还 是 这 个 ConfigMap。 


apiVersion: v1 
kind: ConfigMap 
metadata: 
name: special-config 
namespace: default 
data: 
special.how: very 
special.type: charm 


在 数据 卷 里 面 使 用 这 个 ConfigMap， 有 不 同 的 选项 。 最 基本 的 就 是 将 文件 填 入 数据 
卷 ， 在 这 个 文件 中 ， 键 就 是 文件 名 ， 键 值 就 是 文件 内 容 : 


apiVersion: vi 
kind: Pod 
metadata: 
name: dapi-test-pod 
spec: 
containers: 
- name: test-container 
image: gcr.io/google containers/busybox 
command: [ "/bin/sh", "-c", "cat /etc/config/special.how" ] 


volumeMounts: 
- name: config-volume 
mountPath: /etc/config 


volumes: 
- name: config-volume 
configMap: 


name: special-config 
restartPolicy: Never 


| 
运行 这 个 Pod 的 输出 是 very 。 


我 们 也 可 以 在 ConfigMap 值 被 映射 的 数据 卷 里 控制 路 径 。 


apiVersion: v1 
kind: Pod 
metadata: 
name: dapi-test-pod 
spec: 
containers: 
- name: test-container 
image: gcr.io/google_containers/busybox 
command: [ "/bin/sh","-c","cat /etc/config/path/to/special 


-key" ] 

volumeMounts: 

- name: config-volume 
mountPath: /etc/config 

volumes: 
- name: config-volume 

configMap: 
name: special-config 
items: 


- key: special.how 
path: path/to/special-key 
restartPolicy: Never 


运行 这 个 Pod 后 的 结果 是 very 。 
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ConfigMap 4) # Æ #7 


ConfigMap 有 是 用 来 存储 配置 文件 的 kubernetes 资 源 对 象 ， 所 有 的 配置 内 容 都 存储 在 
etcd 中 ， 下 文 主要 是 探究 ConfigMap 的 创建 和 更 新 流程 ， 以 及 对 ConfigMap 更 新 
后 容器 内 挂 载 的 内 容 是 否 同步 更 新 的 测试 。 


测试 示例 


假设 我 们 在 ”default namespace 下 有 一 个 名 为 nginx-config 的 
ConfigMap， 可 以 使 用 kubectl 命令 来 获取 : 


$ kubectl get configmap nginx-config 
NAME DATA AGE 
nginx-config 1 99d 


获取 该 ConfigMap 的 内 容 。 


kubectl get configmap nginx-config -0 yaml 


apiVersion: vi 
data: 
nginx.conf: |- 
worker processes 1; 


events { worker connections 1024; } 


http 1 
sendfile on; 


server ( 
listen 80; 


# a test endpoint that returns http 200s 
location / { 
proxy pass http://httpstat.us/200; 
proxy set header X-Real-IP $remote_addr; 


j 


server ( 


listen 80; 
server_name api.hello.world; 


location / { 
proxy_pass http://15d.default.svc.cluster.local; 
proxy set header Host $host; 
proxy set header Connection ""; 
proxy http version 1.1; 


more clear input headers 'l5d-ctx-*' '15d-dtab' 
' 15d-sample'; 


} 
} 
server { 
listen 80; 
server_name www.hello.world; 
location / { 
# allow 'employees' to perform dtab overrides 
if ($cookie special employee cookie != "letmein") 
{ 
more clear input headers '15d-ctx-*' '15d-dtab' 
'15d-sample'; 
} 
# add a dtab override to get people to our beta, 
world-v2 
set $xheader ""; 
if ($cookie special employee cookie -* "dogfood") 
{ 
set $xheader "/host/world => /srv/world-v2;"; 
} 
proxy set header '15d-dtab' $xheader; 
proxy pass http://15d.default.svc.cluster.local; 
proxy set header Host $host; 
proxy set header Connection ""; 
proxy http version 1.1; 
} 
} 
} 
kind: ConfigMap 
metadata: 


creationTimestamp: 2017-08-01T06:53:17Z 
name: nginx-config 
namespace: default 


ConfigMap 的 热 更 新 


resourceVersion: "14925806" 
selfLink: /api/vi/namespaces/default/configmaps/nginx-config 
uid: 18d70527-7686-11e7-bfbd-8afie3a7c5bd 


ee || 


ConfigMap 中 的 内 容 是 存储 到 etcd 中 的 ， 然 后 查询 etcd : 


ETCDCTL_API=3 etcdctl get /registry/configmaps/default/nginx-con 
fig -w json|python -m json.tool 


注意 使 用 v3 版 本 的 etcdctl API， 下 面 是 输出 结果 : 


"count © dy 

"header": { 
"cluster id": 12091028579527406772, 
"member id": 16557816780141026208, 
"raft term": 36, 
"revision": 29258723 

ty 

"kys" i [ 
{ 

"create_revision": 14925806, 

"key": "L3J1Z21zdHJ5L2NvbmZpZ21hcHMvZGVmYXVsdC9uZ21u 
eC1jb25maWc-", 

"mod revision": 14925806, 

"value": "azhzAAoPCgJ2MRI JQ29uzmlnTWFwEqQMC1QKDG5naW 
54LWNvbmZpZxIAGgdkZWZhdWxOIgAqJDEAZDCwNTISLTC20DYtMTFl1Ny1iZmJkLT 
hhzjFl1M2b3YzViZDIAOABCCWwj dyoDMBRC5ss54egASywsKCm5naW54LmNvbmYSvA 
t3b3JrZXJfcHJvY2Vzc2VzIDE7CgpldmvudHMgeyB3b3JrZXJf Y29ubmv j dGlvbn 
MgMTAyNDsgfQoKaHROCCB7CiAgICBzZWB5kZmlsZSBvb;jsKCiAgICBzZXJ2ZXIgew 
OgICAgICAgIGxpc3RlbiAAMDsKCiAgICAgICAgIyBhIHRlc3QgZW5kcG9pbnQgdG 
hhdCByZXRi1cm5zIGhOdHAgMjAwcwogICAgICAgIGxvY2FO0aW9uIC8gewogICAgIC 
AgICAgICBwcm94eV9wYXNzIGhOdHA6Ly9odHRwc3RhdC51cy8yMDA7CiAgICAgIC 
AgICAgIHByb3h5X3NldF90ZWFkZXIgIFgtUmVhbCiJUCAgJHJlbW90ZV9hZGRyOw 
OgICAgICAgIHOKICAgIHOKCiAgICBzZXJ2ZXIgewoKICAgICAgICBsaXNO0ZWAgOD 
A7CiAgICAgICAgc2VydmVyX25hbwUgYXBpLmh1bGxvLndvcmxkOwoKICAgICAgIC 
Bsb2NhdGlvbiAvIHsKICAgICAgICAgICAgcHJveHlfcGFzcyBodHRwOi8vbDVkLm 
RlZzmF1bHQuc3ZjLmNsdXNOZXIubG9jYWw7CiAgICAgICAgICAgIHByb3h5X3NldF 
90ZWFkZXIgSG9zdCAkaG9zdDsKICAgICAgICAgICAgcHJveHlfc2VOX2hlYWRlci 
BDb25uZWwNOaW9uICIiOwogICAgICAgICAgICBwcm94eV9odHRwX3ZlcnNpb24gMS 
4XOWwOKICAgICAgICAgICAgbW9yZV9jbGVhcl9pbnBi1dF90ZWFkZXJzICdsNWQtY3 
RALSonICdsNWQtZHRhYicgJ2wi1ZCizYWi1wbGUnOwogICAgICAgIHOKICAgIHOKCi 
AgICBzZXJ2ZXIgewoKICAgICAgICBsaXN0ZWAgODA7CiAgICAgICAgc2VydmVyX2 
5hbwUgd3d3LmhlbGxvLndvcmxkOwoKICAgICAgICBsb2NhdGlvbiAvIHsKCgogIC 
AgICAgICAgICAjIGFsbG931CdlbXBsb311ZXMnIHRvIHBlcmZzvcmOgZHRhYiBvdm 
VycmlkZXMKICAgICAgICAgICAgaWYgKCRjb29rawVfc3BlY2lhbF9lbXBsb311ZV 
9jb29raWUgITOgImxldGi1laW4iKSB7CiAgICAgICAgICAgICAgbW9yZV9jbGVhcl 
9pbnBidF90ZWFkZXJzICdsNWQtY3RALSonICdsNWQtZHRhYicgJ2w1ZC1zYWi1wbG 
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UnOwogICAgICAgICAgICB9CgogICAgICAgICAgICAj IGFkZCBhIGROYWIgb3Z1cn 
JpZGUgdG8gZ2VOIHBlb3BsZSBObyBvdXIgYmVOYSwgd29ybGQtd;jIKICAgICAgIC 
AgICAgc2VOICRA4aGVhZGVyICIiOwWOKICAgICAgICAgICAgaWYgKCRjb29raWVfc3 
BlY21hbF9lbXBsb311ZV9jb29rawUgfiogImRvZ2Zvb2QiKSB7CiAgICAgICAgIC 
AgICAgc2VOICRA4aGVhZGVyICIvaG9zdC93b3JsZCA9PiAvc3J2L3dvcmxkLXYyOy 
I7CiAgICAgICAgICAgIHOKCiAgICAgICAgICAgIHByb3h5X3NldF90ZWFkZXIgJ2 
w1ZCikdGFiJyAkeGhlYWRlcjsKCgogICAgICAgICAgICBwcm94eV9wYXNz IGhOdH 
A6Ly9sNWQuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDsKICAgICAgICAgICAgcH 
JveHlfc2VOX2hlYWRlciBIb3NOICRob3NOOwogICAgICAgICAgICBwCcm94eV9zZX 
RfaGVhZGVyIENvbm5lY3Rpb24glil7CiAgICAgICAgICAgIHByb3h5X2hO0dHBfdm 
Vyc21vbiAxLjE7CiAgICAgICAgfQogICAgfQp9GgAiAA--", 
"version": 1 
} 


其 中 的 value 就 是 nginx.conf 配置 文件 的 内 容 。 


可 以 使 用 pase64 解 码 查 看 具体 值 ， 关于 etcdctl 的 使 用 请 参考 使 用 etcdctl 访 问 
kuberentes 数 据 。 


代码 


ConfigMap 结构 体 的 定义 : 


// ConfigMap holds configuration data for pods to consume. 
type ConfigMap struct { 

metavi.TypeMeta '^json:",inline"' 

// Standard object's metadata. 

// More info: http://releases.k8s.io/HEAD/docs/devel/api-con 
ventions.mdzmetadata 

// *optional 

metavi.ObjectMeta '^json:"metadata,omitempty" protobuf:"bytes 
,1,0pt,namezmetadata"' 


// Data contains the configuration data. 

// Each key must be a valid DNS SUBDOMAIN with an optional 1l 
eading dot. 

// *optional 

Data map[string]string '^json:"data,omitempty" protobuf:"byte 
s,2,rep,name-data"" 


在 staging/src/k8s.io/client- 
go/kubernetes/typed/core/vi/configmap.go "T ConfigMap 的 接口 定义 : 
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// ConfigMapinterface has methods to work with ConfigMap resourc 
es. 
type ConfigMapInterface interface { 
Create(*vi.ConfigMap) (*vi.ConfigMap, error) 
Update(*vi.ConfigMap) (*vi.ConfigMap, error) 
Delete(name string, options *meta vi.DeleteOptions) error 
DeleteCollection(options *meta_v1.DeleteOptions, listOptions 
meta vi.ListOptions) error 
Get(name string, options meta vi.GetOptions) (*vi.ConfigMap, 
error) 
List(opts meta vi.ListOptions) (*vi.ConfigMapList, error) 
Watch(opts meta vi.ListOptions) (watch.Interface, error) 
Patch(name string, pt types.PatchType, data []byte, subresou 
rces ...string) (result *v1.ConfigMap, err error) 
ConfigMapExpansion 


E ay 


在 staging/src/k8s.io/client - 
go/kubernetes/typed/core/vi/configmap.go 中 创建 ConfigMap 的 方法 如 下 : 


// Create takes the representation of a configMap and creates it 
Returns the server's representation of the configMap, and an 
error, if there is any. 
func (c *configMaps) Create(configMap *vi.ConfigMap) (result *v1. 
ConfigMap, err error) { 
result = &v1.ConfigMap{} 
err = c.client.Post(). 
Namespace(c.ns). 
Resource("configmaps"). 
Body(configMap). 
Do(). 
Into(result) 
return 


j 
E Er E 


通过 RESTful 请 求 在 etcd 中 存储 ConfigMap 的 配置 ， 该 方法 中 设置 了 资源 对 象 的 
namespace 和 HTTP 请 求 中 的 body， 执 行 后 将 请 求 结 果 保 存 到 result 中 返回 给 调 
用 者 。 


注意 Body 的 结构 


ConfigMap 的 热 更 新 


// Body makes the request use obj as the body. Optional. 

// If obj is a string, try to read a file of that name. 

// If obj is a []byte, send it directly. 

// If obj is an io.Reader, use it directly. 

// If obj is a runtime.Object, marshal it correctly, and set Con 
tent-Type header. 

// If obj is a runtime.Object and nil, do nothing. 

// Otherwise, set an error. 


创建 ConfigMap RESTful 请 求 中 的 的 Body 中 包含 0bjectMeta 和 


Namespace ° 


HTTP 请 求 中 的 结构 体 : 
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// Request allows for building up a request to a server in a cha 
ined fashion. 
// Any errors are stored until the end of your call, so you only 
have to 
// check once. 
type Request struct { 

// required 

client HTTPClient 

verb string 


baseURL *url.URL 
content ContentConfig 
serializers Serializers 


// generic components accessible via method setters 
pathPrefix string 

subpath string 

params url.Values 

headers http.Header 


// structural elements of the request that are part of the K 
ubernetes API conventions 


namespace string 
namespaceSet bool 
resource string 


resourceName string 
subresource string 
timeout time.Duration 


// output 

err error 

body io.Reader 

// This is only used for per-request timeouts, deadlines, an 
d cancellations. 

ctx context.Context 


backoffMgr BackoffManager 
throttle flowcontrol.RateLimiter 


i] ix 


分 别 测试 使 用 ConfigMap 1€ 3X Env 和 Volume 的 情况 。 


更 新 使 用 ConfigMap 挂 载 的 Env 


使 用 下 面 的 配置 创建 nginx 容器 测试 更 新 ConfigMap 后 容器 内 的 环境 变量 是 否 也 跟 
着 更 新 。 


apiVersion: extensions/vibetal 
kind: Deployment 
metadata: 

name: my-nginx 
spec: 

replicas: 1 

template: 

metadata: 

labels: 
run: my-nginx 

spec: 

containers: 

- name: my-nginx 
image: harbor-001.jimmysong.io/library/nginx:1.9 
ports: 

- containerPort: 80 
envFrom: 
- configMapRef: 
name: env-config 
apiVersion: vi 
kind: ConfigMap 
metadata: 
name: env-config 
namespace: default 
data: 
log level: INFO 


获取 环境 变量 的 值 


$ kubectl exec ^"kubectl get pods -1 run=my-nginx  -o-name|cut -d 
"/" -f2? env|grep log level 
log level-INFO 


到 二 sO 


修改 ConfigMap 


$ kubectl edit configmap env-config 


修改 log level 442A DEBUG ° 


再 次 查看 环境 变量 的 值 。 


$ kubectl exec “kubectl get pods -1 run=my-nginx  -o-name|cut -d 
"/" -f2? env|grep log level 
log level-INFO 
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实践 证 明 修改 ConfigMap 无 法 更 新 容器 中 已 注入 的 环境 变量 信息 。 


更 新 使 用 ConfigMap 挂 载 的 Volume 


使 用 下 面 的 配置 创建 nginx 容器 测试 更 新 ConfigMap 后 容器 内 挂 载 的 文件 是 否 也 跟 
着 更 新 。 


apiVersion: extensions/vibeta1 
kind: Deployment 
metadata: 
name: my-nginx 
spec: 
replicas: 1 
template: 
metadata: 
labels: 
run: my-nginx 
spec: 
containers: 
- name: my-nginx 
image: harbor-001.jimmysong.io/library/nginx:1.9 
ports: 
- containerPort: 80 
volumeMounts: 
- name: config-volume 
mountPath: /etc/config 


volumes: 
- name: config-volume 
configMap: 


name: special-config 
apiVersion: v1 
kind: ConfigMap 
metadata: 
name: special-config 
namespace: default 
data: 
log level: INFO 


$ kubectl exec “kubectl get pods -1 run=my-nginx  -o-name|cut -d 
"U/" -f2? cat /tmp/log level 
INFO 


可 - 








修改 ConfigMap 


$ kubectl edit configmap special-config 


修改 log level 4A DEBUG ° 


等 待 大 概 10 秒 钟 时 间 ， 再 次 查看 环境 变量 的 值 。 


$ kubectl exec ^"kubectl get pods -1 run=my-nginx  -o-name|cut -d 
"/" -f2? cat /tmp/log_ level 
DEBUG 


li mc———nÀ———— ——À— —  Á ee |) 


我 们 可 以 看 到 使 用 ConfigMap 方式 挂 载 的 Volume 的 文件 中 的 内 容 已 经 变 成 了 
DEBUG 。 


ConfigMap 更 新 后 滚动 更 新 Pod 


更 新 ConfigMap 目前 并 不 会 触发 相关 Pod 的 滚动 更 新 ， 可 以 通过 修改 pod 
annotations 的 方式 强制 触发 滚动 更 新 。 


$ kubectl patch deployment my-nginx --patch '{"spec": {"template 
": {"metadata": {"annotations": {"version/config": "20180411" }} 


th}! 


这 个 例子 里 我 们 在 .spec.template.metadata.annotations 中 添加 
version/config ， 每 次 通过 修改 version/config 来 触发 滚动 更 新 。 


K 


` gx 


NY 一 


C 


更 新 ConfigMap 后 : 


e 使 用 该 ConfigMap 挂 载 的 Env 不 会 同步 更 新 


e 使 用 该 ConfigMap 挂 载 的 Volume 中 的 数据 需要 一 段 时 间 (实测 大 概 10 秒 ) 才 
能 同步 更 新 


ENV 是 在 容器 启动 的 时 候 注入 的 ， 启 动 之 后 kubernetes 就 不 会 再 改变 环境 变量 的 
值 ， 且 同一 个 namespace 中 的 pod 的 环境 变量 是 不 断 累 加 的 ， 参 考 Kubernetes 中 
的 服务 发 现 与 docker 容 器 间 的 环境 变量 传递 源码 探究 。 为 了 更 新 容器 中 使 用 
ConfigMap 挂 载 的 配置 ， 需 要 通过 滚动 更 新 pod 的 方式 来 强制 重新 挂 载 
ConfigMap ° 


e Kubernetes 1.7 security in practice 
e ConfigMap | kubernetes handbook - jimmysong.io 
e 创建 高 可 用 ectd 集 群 | Kubernetes handbook - jimmysong.io 


e Kubernetes 中 的 服务 发 现 与 docker 容 器 间 的 环境 变量 传递 源码 探究 
e Automatically Roll Deployments When ConfigMaps or Secrets change 
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Volume 


容器 磁盘 上 的 文件 的 生命 周期 是 短暂 的 ， 这 就 使 得 在 容器 中 运行 重要 应 用 时 会 出 现 
梧 题 。 首 先 ， 当 容器 崩溃 时 ，kubelet 会 重启 它 ， 但 是 容器 中 的 文件 将 丢失 
ous — (镜像 最 初 的 状态 ) 重新 启动 。 其 次 ， 在 Pod 中 同时 运行 
多 个 容器 时 ， 这 些 容器 之 间 通 常 需要 共享 文件 。Kubernetes 中 的 volume 抽象 就 

E i 解决 Pe x 35 Je 此 问题 





建议 先 熟悉 pod ° 


Ab 
H GE 


Docker 中 也 有 一 个 volume 的 概念 ， 尽 管 它 稍微 宽松 一 些 ， 管 理 也 很 少 。 在 
Docker 中 ， 卷 就 像 是 磁 瘟 或 是 另 一 个 容器 中 的 一 个 目录 。 它 的 生命 周期 不 受 管 
理 ， 直 到 最 近 才 有 了 local-disk-backed & ° Docker 现在 提供 了 卷 驱动 程序 ， 但 是 

能 还 非常 有 限 (例如 Docker1.7 只 允许 每 个 容器 使 用 一 个 卷 驱 动 ， 并 且 无 法 给 卷 
ek 


53 —3 di * Kubernetes 中 的 卷 有 明确 的 寿命 REN Pod 相同 。 所 以 ， 卷 
的 生命 比 Pod 中 的 所 有 容器 都 长 ， 当 这 个 容器 重启 时 数据 仍然 得 以 保存 。 当 然 ， 当 
Pod 不 再 存在 时 ， 卷 也 将 不 复 存 在 。 也 许 更 重要 的 是 ，Kubernetes 支持 多 种 类 型 
的 卷 ，Pod 可 以 同时 使 用 任意 数量 的 卷 。 





卷 的 核心 是 目录 ， 可 能 还 包含 了 一 些 数据 ， 可 以 通过 pod 中 的 容器 来 访问 。 该 目录 
是 如 何 形成 的 、 支 持 该 目录 的 介质 以 及 其 内 容 取决 于 所 使 用 的 特定 卷 类 型 。 


要 使 用 卷 ， 需 要 为 pod 48744 ( spec.volumes 字段 ) 以 及 将 它 挂 载 到 容器 的 


位 置 ( spec.containers.volumeMounts 字段 ) » 


容器 中 的 进程 看 到 的 是 由 其 Docker 镜像 和 卷 组 成 的 文件 系统 视图 。 Docker 镜像 
位 于 文件 系统 层次 结构 的 根 目 录 ， 任 何 卷 都 被 挂 载 在 镜像 的 指定 路 径 中 。 卷 无 法 挂 
载 到 其 他 卷 上 或 与 其 他 卷 有 硬 连 接 。Pod 中 的 每 个 容器 都 必须 独立 指定 每 个 卷 的 挂 
载 位 置 e 


卷 的 类 型 


Kubernetes 支持 以 下 类 型 的 卷 : 


e awsElasticBlockStore 
e azureDisk 

e azureFile 

e cephfs 

e csi 

e downwardAPI 

e emptyDir 

e fc (fibre channel) 

e flocker 


e gcePersistentDisk 


e gitRepo 

e glusterfs 
e hostPath 
e iscsi 

e local 

e nfs 


e persistentVolumeClaim 
e projected 

e portworxVolume 

e quobyte 

e rbd 

e scaleI0 

e secret 

e storageos 


e vsphereVolume 


我 们 欢迎 额外 贡献 。 


awsElasticBlockStore 


awsElasticBlockStore 卷 将 Amazon Web Services (AWS) EBS Volume 挂 载 
到 您 的 容器 中 。 与 emptyDir 会 在 删除 Pod 时 被 清除 不 同 ，EBS 卷 的 的 内 
eet ， 仅 仅 是 被 卸载 。 这 意味 着 EBS 卷 可 以 预先 填充 数据 ， 并 且 可 以 在 
数据 包 之 间 "“ 切 换 ” 数 据 。 


重要 提示 : 您 必须 使 用 aws ec2 create-volume 或 AWS API 创建 


能 使 用 它 。 
使 用 awsElasticBlockStore 卷 时 有 一 些 限 制 : 


e 运行 Pod 的 节点 必须 是 AWS EC2 实例 
e 这 些 实 例 需要 与 EBS 卷 位 于 相同 的 区 域 和 可 用 区 域 
EBS 仅 支 持 卷 和 EC2 实例 的 一 对 一 的 挂 载 


创建 EBS & 


在 pod 中 使 用 的 EBS 卷 之 前 ， 您 需要 先 创建 它 。 


£ EBS $T 


aws ec2 create-volume --availability-zone-eu-west-1a --size-10 - 


-volume -type=gp2 


确保 区 域 与 您 启动 集群 的 区 域 相 匹配 (并 且 检 查 大 小 和 EBS EK 
使 用 上 ! ) 


AWS EBS 示例 配置 


apiVersion: vi 
kind: Pod 
metadata: 

name: test-ebs 

spec: 

containers: 

- image: k8s.gcr.io/test-webserver 
name: test-container 
volumeMounts: 

- mountPath: /test-ebs 
name: test-volume 


volumes: 
- name: test-volume 
4 This AWS EBS volume must already exist. 


awsElasticBlockStore: 
volumeID: «volume-id» 
fsType: ext4 


azureDisk 


AzureDisk 用 于 将 Microsoft Azure Data Disk 4 #2 Pod 中。 


A 


日 


AET 


适合 您 的 


更 多 细节 可 以 在 这 里 找到 。 


azureFile 


azureFile 用 于 将 Microsoft Azure File Volume (SMB 2.1 fe 3.0) 挂 载 到 Pod 
Po 


更 多 细节 可 以 在 这 里 找到 。 


cephfs 


cephfs 卷 允 许 将 现 有 的 CephFS 4&1: 33 21 fi REP o KR emptyDir > Z4 
除 Pod 时 被 删除 ， cephfs 卷 的 内 容 将 被 保留 ， 卷 仅仅 是 被 和 卸载 。 这 意味 着 
CephFS 卷 可 以 预先 填充 数据 ， 并 且 可 以 在 数据 包 之 间 * 切 换 " 数 据 。CephFS 可 以 
被 多 个 写 设 备 同 时 挂 载 。 


重要 提示 : 您 必须 先 拥 有 自己 的 Ceph 服务 器 ， 然 后 才能 使 用 它 。 


有 关 更 多 详细 信息 ， 请 参见 CephFS 示 例 。 


csi 


CSI 代表 容器 存储 接口 ，CSI| 试图 建立 一 个 行业 标准 接口 的 规范 ， 借 助 CSI 容器 编 
HEAR (CO) 可 以 将 任意 存储 系统 暴露 给 自己 的 容器 工作 人 负载。 有关 详细 信息 ， 


请 查看 设计 方案 。 


csi 卷 类 型 是 一 种 in-tree 的 CSI 卷 插 件 ， 用 于 Pod 与 在 同一 节点 上 运行 的 外 部 
CSI 卷 驱动 程序 交互 。 部 署 CS| 兼容 卷 驱动 后 ， 用 户 可 以 使 用 csi 作为 卷 类 型 来 
挂 载 驱动 提供 的 存储 。 


CSI 持久 化 卷 支持 是 在 Kubernetes v1.9 中 引入 的 ， 作 为 一 个 alpha 特性， 必须 由 
集群 管理 员 明 确 启用 。 换 和 句 话说 ， 集 群 管理 员 需 要 在 apiserver ` controller- 
manager 和 kubelet 组 件 的 “ --feature-gates = ”标志 中 加 上 


" CSIPersistentVolume = true ”° 
CSI 持久 化 卷 具有 以 下 字段 可 供用 户 指 定 : 


e driver :一 个 字符 串 值 ,指定 要 使 用 的 卷 驱 动 程序 的 名 称 。 必 须 少 于 63 个 
字符 ， 并 以 一 个 字符 开头 。 了 驱动 程序 名 称 可 以 包含 “,”、“ - ”、“ RH 


ue 

e volumeHandle :一 个 字符 囊 值 ， 唯一 标识 从 CSI 卷 插件 的 
CreateVolume 调用 返回 的 卷 名 。 随 后 在 卷 驱 动 程序 的 所 有 后 续 调 用 中 使 用 
卷 句柄 来 引用 该 卷 。 

e readonly :一 个 可 选 的 布尔 值 ， 指 示 卷 是 否 被 发 布 为 只 读 。 上 默认 是 false。 


downwardAPI 


downwardAPI 卷 用 于 使 向 下 API 数据 (downward API data) 对 应 用 程序 可 用 。 
它 挂 载 一 个 目录 ， 并 将 请 求 的 数据 写 入 纯 文本 文件 。 


参考 downwardAPI 卷 示例 查看 详细 信息 。 


emptyDir 


4 Pod 被 分 配给 节点 时 ， 首 先 创建 emptyDir 卷 ， 并 且 只 要 该 Pod 在 该 节点 上 

运行 ， 该 卷 就 会 存在 。 正 如 卷 的 名 字 所 述 ， 它 最 初 是 空 的 。Pod 中 的 容器 可 以 读 取 
和 写 入 emptyDir 卷 中 的 相同 文件 ， 尽 管 该 卷 可 以 挂 载 到 每 个 容器 中 的 相同 或 不 
同 路 径 上 。 当 出 于 任何 原因 从 节点 中 删除 Pod 时， emptyDir 中 的 数据 将 被 永久 
删除 。 


注意 : 容器 前 溃 不 会 从 节点 中 移 除 pod， 因 此 emptyDir 卷 中 的 数据 在 容器 崩溃 
时 是 安全 的 。 


emptyDir 的 用 法 有 : 


e ERE ee 
e 用 作 长 时 间 计 算 崩 溃 恢 复 时 的 检查 
e Web 服务器 容器 提供 数据 时 ， 保 趣 内 容 管理 器 容 器 提取 的 文件 


Pod 示例 


apiVersion: v1 
kind: Pod 
metadata: 

name: test-pd 

spec: 

containers: 

- image: k8s.gcr.io/test-webserver 
name: test-container 
volumeMounts: 

- mountPath: /cache 
name: cache-volume 
volumes: 

- name: cache-volume 
emptyDir: {} 


fc (fibre channel) 


fc 卷 允 许 将 现 有 的 fc 卷 挂 载 到 pod 中 。 您 可 以 使 用 卷 配置 中 的 targetwwn #& 
数 指定 单个 或 多 个 目标 全 球 通 ers (World Wide Name) 。 如 果 指 定 了 多 个 
WWN ， 则 targetWWN 期 望 这 些 WWN 来 自 多 路 径 连 接 。 


重要 提示 : 您 必须 配置 FC SAN 区 域 划分 ， 并 预先 将 这 些 LUN ( 卷 ) 分 配 并 屏蔽 
到 目标 WWN， 以 便 Kubernetes 主机 可 以 访问 它们 。 


参考 FC 示例 获取 详细 信息 。 


flocker 


Flocker 是 一 款 开 源 的 集群 容器 数据 卷 管理 器 。 它 提供 了 由 各 种 存储 后 端 支持 的 数 
据 卷 的 管理 和 编排 。 


flocker 允许 将 Flocker 数据 集 挂 载 到 pod 中 。 如 果 数 据 集 在 Flocker 中 不 存 
在 ， 则 需要 先 使 用 Flocker CLI 或 使 用 Flocker API 创建 数据 集 。 如 果 数 据 集 已 经 存 
在 ， 它 将 被 Flocker 重新 连接 到 pod 被 调度 的 节点 上 。 这 意味 着 数据 可 以 根据 需要 
在 数据 包 之 间 “ 切 换 ”。 


重要 提示 : 您 必须 先 运行 自己 的 Flocker 安装 程序 才能 使 用 它 。 


参考 Flocker 示例 获取 更 多 详细 信息 。 


gcePersistentDisk 


gcePersistentDisk #44 Google Compute Engine (GCE) Persistent Disk 4& 
载 到 您 的 容器 中 。 与 删除 Pod 时 删除 的 emptyDir 不 同 ，PD 的 内 容 被 保留 ， 只 
是 卸载 了 卷 。 这 意味 着 PD 可 以 预先 填充 数据 ， 并 且 数 据 可 以 在 Pod 之 间 “ 切 换 ”。 


重要 提示 : 您 必须 先 使 用 gcloud 或 GCE API 或 UI 创建 一 个 PD， 然 后 才能 使 用 


o 


e 
使 用 gcePersistentDisk 时 有 一 些 限 制 : 


e 运行 Pod 的 节点 必须 是 GCE 虚拟 机 
。 那 些 庶 拟 机 需要 在 与 PD 一 样 在 GCE 项 目 和 区 域 中 


PD 的 一 个 特点 是 它们 可 以 同时 被 多 个 用 户 以 只 读 方式 挂 载 。 这 意味 着 您 可 以 预先 
使 用 您 的 数据 集 填 充 PD， 然 后 根据 需要 给 多 个 Pod 中 并 行 提 供 。 不 幸 的 是 ， 只 能 
由 单个 消费 者 以 读 写 模 式 挂 载 PD， 而 不 允许 同时 写 入 。 在 由 
ReplicationController 控制 的 pod 上 使 用 PD 将 会 失败 ， 除 非 PD 是 只 读 的 或 者 副 
本 数 是 0 或 1。 


创建 PD 


在 您 在 pod 中 使 用 GCE PD 之 前 ， 需 要 先 创建 它 。 


gcloud compute disks create --size-500GB --zone-us-centrali-a my 
-data-disk 


Pod 示例 


apiVersion: v1 
kind: Pod 
metadata: 

name: test-pd 

spec: 

containers: 

- image: k8s.gcr.io/test -webserver 
name: test-container 
volumeMounts: 

- mountPath: /test-pd 
name: test-volume 

volumes: 

- name: test-volume 
# This GCE PD must already exist. 
gcePersistentDisk: 

pdName: my-data-disk 
fsType: ext4 


gitRepo 


gitRepo 卷 是 一 个 可 以 演示 卷 播 件 功能 的 示例 。 它 会 挂 载 一 个 空 目录 并 将 git 存 
储 库 克 隆 到 您 的 容器 中 。 将 来 ， 这 样 的 卷 可 能 会 转移 到 一 个 更 加 分 离 的 模型 ， 而 不 
是 为 每 个 这 样 的 用 例 扩 展 Kubernetes API » 


下 面 是 gitRepo 卷 示例 : 


apiVersion: vi 
kind: Pod 
metadata: 
name: server 
spec: 
containers: 
- image: nginx 
name: nginx 
volumeMounts: 
- mountPath: /mypath 
name: git-volume 
volumes: 
- name: git-volume 
gitRepo: 
repository: "git@somewhere:me/my-git-repository.git" 
revision: "22f1d8406d464b0c0874075539c1f2e96c253775" 


glusterfs 


glusterfs 卷 允 许 将 Glusterfs 〈 一 个 开放 源 代码 的 网 络 文件 系统 ) 卷 挂 载 到 您 
的 集群 中 。 与 删除 Pod 时 删除 的 emptyDir 不 同 ， glusterfs 卷 的 内 容 将 被 保 
留 ， 而 卷 仅仅 被 扼 载 。 这 意味 着 glusterfs 卷 可 以 预先 填充 数据 ， 并 且 可 以 在 数据 包 
之 间 “ 切 换 " 数 据 。 GlusterFS 可 以 同时 由 多 个 写 入 挂 载 。 


重要 提示 : 您 必须 先 自行 安装 GlusterFS， 才 能 使 用 它 。 


有 关 更 多 详细 信息 ， 请 参阅 GlusterFS 示例 。 


hostPath 


hostPath 卷 将 主机 节点 的 文件 系统 中 的 文件 或 目录 挂 载 到 集群 中 。 该 功能 大 多 
数 Pod 都 用 不 到 ， 但 它 为 某 些 应 用 程序 提供 了 一 个 强大 的 解决 方法 。 


例如 ， hostPath 的 用 途 如 下 : 


e 运行 需要 访问 Docker 内 部 的 容器 ; 使 用 /var/lib/docker 的 hostPath 

e 在 容器 中 运行 cAdvisor ; 使 用 /dev/cgroups  hostPath 

e 允许 pod 指定 给 定 的 hostPath 是 否 应 该 在 pod 运行 之 前 存在 ， 是 否 应 该 创 
建 ， 以 及 它 应 该 以 什么 形式 存在 


除了 所 需 的 path 属性 之 外 ， 用 户 还 可 以 为 hostPath 卷 指定 type ° 


type 字段 支持 以 下 值 : 


DirectoryOrCreate 


Directory 


FileOrCreate 


File 
Socket 
CharDevice 


BlockDevice 


行为 


空 字符 串 (RU) 用 于 向 后 兼容 ， 这 意味 着 在 挂 载 
hostPath 卷 之 前 不 会 执行 任何 检查 。 


如 果 在 给 定 的 路 径 上 没有 任何 东西 存在 ， 那 么 将 根据 
需要 在 那里 创建 一 个 空 目录 ， 权 限 设 置 为 0755 ;与 
Kubelet 具有 相同 的 组 和 所 有 权 。 


给 定 的 路 径 下 必须 存在 目录 


如 果 在 给 定 的 路 径 上 没有 任何 东西 存在 ， 那 么 会 根据 
需要 创建 一 个 空 文件 ， 权 限 设 置 为 0644 * 5 Kubelet 
具有 相同 的 组 和 所 有 权 。 


给 定 的 路 径 下 必须 存在 文件 

给 定 的 路 径 下 必须 存在 UNIX 套 接 字 
给 定 的 路 径 下 必须 存在 字符 设备 
给 定 的 路 径 下 必须 存在 块 设备 


使 用 这 种 卷 类 型 是 请 注意 ， 因 为 : 


e 由 于 每 个 节点 上 的 文件 都 不 同 ， 具 有 相同 配置 (例如 从 podTemplate 创建 的 ) 
的 pod 在 不 同 节 点 上 的 行为 可 能 会 有 所 不 同 
e 3 Kubernetes 按照 计划 添加 资源 感知 调度 时 ， 将 无 法 考虑 hostPath 使 用 


的 资源 


e 在 底层 主机 上 创建 的 文件 或 目录 只 能 由 root 写 入 。 您 需要 在 特权 容器 中 以 root 
身份 运行 进程 ， 或 修改 主机 上 的 文件 权限 以 便 写 入 hostPath 卷 


Pod 示例 


apiVersion: v1 
kind: Pod 
metadata: 

name: test-pd 

spec: 

containers: 

- image: k8s.gcr.io/test -webserver 
name: test-container 
volumeMounts: 

- mountPath: /test-pd 
name: test-volume 

volumes: 

- name: test-volume 
hostPath: 

# directory location on host 
path: /data 

# this field is optional 
type: Directory 


iscsi 


iscsi 卷 允 许 将 现 有 的 iSCSI (SCSI over IP) ERIRE YF o KR 
emptyDir > MIM Pod 时 iscsi 卷 的 内 容 将 被 保留 ， 卷 仅仅 是 被 卸载 。 这 意味 
着 iscsi 卷 可 以 预先 填充 数据 ， 并 且 这 些 数据 可 以 在 pod 之 问 “ 切 换 ”。 


重要 提示 : 必须 先 创 建 自 己 的 iSCSI 服务 器 ， 然 后 才能 使 用 它 。 


iSCSI 的 一 个 特点 是 它 可 以 同时 被 多 个 用 户 以 只 读 方式 安装 。 这 意味 着 您 可 以 预先 
使 用 您 的 数据 集 填充 卷 ， 然 后 根据 需要 向 多 个 额 pod 同时 提供 。 不 幸 的 是 ，iSCSI 
卷 只 能 由 单个 使 用 者 以 读 写 模式 挂 载 不 允许 同时 写 入 





有 关 更 多 详细 信息 ， 请 参见 iSCSI 示例 。 


local 


这 个 alpha 功能 要 求 启用 PersistentLocalVolumes feature gate ° 
注意 : 从 1.9 开始 ， VolumeScheduling feature gate 也 必须 启用 。 
local 卷 表示 挂 载 的 本 地 存储 设备 ， 如 磁盘 、 分 区 或 目录 。 


本 地 卷 只 能 用 作 静 态 创建 的 PersistentVolume » 


£j HostPath I: W > local 卷 可 以 以 持久 的 方式 使 用 ， 而 无 需 手 动 将 pod 调度 到 节 


点 上 ， 因 为 系统 过 查看 PersistentVolume 上 的 节点 关联 性 来 了 解 卷 的 节点 约 
来 o 
{2% > local 卷 仍然 受 底层 节点 的 可 用 性 影响 ， 并 不 适用 于 所 有 应 用 程序 。 


以 下 是 使 用 local 卷 的 示例 PersistentVolume 规范 : 


apiVersion: v1 
kind: PersistentVolume 


metadata: 
name: example-pv 
annotations: 
"volume.alpha.kubernetes.io/node-affinity": '( 
"requiredDuringSchedulingIgnoredDuringExecution": { 
"nodeSelectorTerms": [ 
{ "matchExpressions": [ 
{ "key": "kubernetes.io/hostname", 
"operator": "In", 
"values": ["example-node"] 
} 
]} 
]} 
i 
spec: 
Capacity: 
storage: 100Gi 
accessModes: 
- ReadwriteOnce 


persistentVolumeReclaimPolicy: Delete 
storageClassName: local-storage 


local: 
path: /mnt/disks/ssdi 


注意 : 本 地 PersistentVolume 清理 和 删除 需要 手动 干预 ,无 外 部 提供 B 


从 1.9 开始 ， 本 地 卷 绑 定 可 以 被 延迟 ， 直 到 通过 具有 StorageClass 中 的 
WaitForFirstConsumer 设置 为 volumeBindingMode 的 pod 开始 调度 。 请 参 
阅 示例 。 延 迟 卷 绑 定 可 确保 卷 绑 定 决 策 也 可 以 使 用 任何 其 他 节点 约束 《例如 节点 资 
源 需 求 ， 节 点 选择 器 ，pod 亲 和 性 和 pod 反 亲 和 性 ) 进行 评估 。 


AK local 卷 类 型 的 详细 信息 ， 请 参见 本 地 持久 化 存储 用 户 指 南 。 


nfs 


nfs 卷 允 许 将 现 有 的 NFS (网 络 文件 系统 ) 共享 挂 载 到 您 的 容器 中 。 不 像 
emptyDir ， 当 删除 Pod H^» nfs 卷 的 内 容 被 保留 ， 卷 仅仅 是 被 卸载 。 这 意味 
着 NFS 卷 可 以 预 填 充 数据 ， 并 且 可 以 在 pod Z “mik žE o NFS 可 以 被 多 个 写 
入 者 同时 挂 载 。 


重要 提示 : 您 必须 先 拥 有 自己 的 NFS 服务 器 才能 使 用 它 ， 然 后 才能 使 用 它 。 


有 关 更 多 详细 信息 ， 请 参见 NFS 示例 。 


persistentVolumeClaim 


persistentVolumeClaim 卷 用 于 将 PersistentVolume 挂 载 到 容器 中 。 
PersistentVolumes 是 在 用 户 不 知道 特定 云 环境 的 细节 的 情况 下 “声明 "持久 化 存储 
(例如 GCE PersistentDisk 或 iSCSI 卷 ) 的 一 种 方式 。 


有 关 更 多 详细 信息 ， 请 参阅 PersistentVolumes 示例 。 


projected 
projected 卷 将 几 个 现 有 的 卷 源 映射 到 同一 个 目录 中 。 
目前 ， 可 以 映射 以 下 类 型 的 卷 来 源 : 


e secret 

e downwardAPI 

e configMap 
所 有 来 源 都 必须 在 与 pod 相同 的 命名 空间 中 。 有 关 更 多 详细 信息 ， 请 参阅 all-in- 
one 卷 设 计 文 档 。 


带 有 secret、downward API 和 configmap 的 pod 


apiVersion: v1 
kind: Pod 
metadata: 
name: volume-test 
spec: 
containers: 
- name: container-test 
image: busybox 
volumeMounts: 
- name: all-in-one 
mountPath: "/projected-volume" 
readOnly: true 
volumes: 
- name: all-in-one 
projected: 
sources: 
- secret: 
name: mysecret 
items: 
- key: username 
path: my-group/my-username 
- downwardAPI: 
items: 
- path: "labels" 
fieldRef: 
fieldPath: metadata.labels 
- path: "cpu limit" 
resourceFieldRef: 
containerName: container-test 
resource: limits.cpu 
- configMap: 
name: myconfigmap 
items: 
- key: config 
path: my-group/my-config 


使 用 非 默 认 权 限 模式 设置 多 个 secret 的 示例 pod 


apiVersion: v1 
kind: Pod 
metadata: 
name: volume-test 
spec: 
containers: 
- name: container-test 
image: busybox 
volumeMounts: 
- name: all-in-one 
mountPath: "/projected-volume" 
readOnly: true 
volumes: 
- name: all-in-one 
projected: 
sources: 
- secret: 
name: mysecret 
items: 
- key: username 
path: my-group/my-username 
- secret: 
name: mysecret2 
items: 
- key: password 
path: my-group/my-password 
mode: 511 


每 个 映射 的 卷 来 源 在 sources 下 的 规格 中 列 出 。 除 了 以 下 两 个 例外 ， 参 数 几乎 相 
B: 
e 对 于 secret? secretName 字段 已 经 被 更 改 为 name 以 与 ConfigMap 命名 
m 
e defaultMode 只 能 在 映射 级 别 指定 ， 而 不 能 针对 每 个 卷 源 指定 。 但 是 ， 如 上 
所 述 ， 您 可 以 明确 设置 每 个 映射 的 mode 。 


portworxVolume 


portworxVolume 是 一 个 与 Kubernetes 一 起 ， 以 超 融 合 模式 运行 的 弹 
层 。Portwork 指纹 存储 在 服务 器 中 ， 基 于 功能 的 分 层 ， 以 及 跨 多 个 服 
量 。 Portworx 在 虚拟 机 或 裸 机 Linux 节点 上 运行 。 

portworxVolume 可 以 通过 Kubernetes 动态 创建 ， 也 可 以 在 Kubernetes pod 中 
预先 设置 和 引用 。 


以 下 是 一 个 引用 预先 配置 的 PortworxVolume 的 示例 pod : 


apiVersion: vi 
kind: Pod 
metadata: 

name: test-portworx-volume-pod 

spec: 

containers: 

- image: k8s.gcr.io/test-webserver 
name: test-container 
volumeMounts: 

- mountPath: /mnt 
name: pxvol 

volumes: 

- name: pxvol 
Z This Portworx volume must already exist. 
portworxVolume: 

volumeID: "pxvol" 
fsType: "«fs-type»" 


重要 提示 : 在 pod 中 使 用 之 前 ， 请 确保 您 有 一 个 名 为 pxvol HHA 
PortworxVolume ° 


更 多 的 细节 和 例子 可 以 在 这 里 找到 。 


quobyte 


quobyte 卷 允 许 将 现 有 的 Quobyte HERIR ZP ° 
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重要 提示 : 您 必须 先 创 建 自己 的 Quobyte 安装 程序 


有 关 更 多 详细 信息 ， 请 参见 Quobyte 示 例 。 


rbd 


rbd 卷 允许 将 Rados Block Device 卷 挂 载 到 容器 中 。 不 像 emptyDir ， 删 除 
Pod 时 rbd 卷 的 内 容 被 保留 ， 卷 仅仅 被 卸载 。 这 意味 着 RBD 卷 可 以 预先 填充 数 
据 ， 并 且 可 以 在 pod 之 间 “ 切 换 " 数 据 。 


重要 提示 : 您 必须 先 自行 安装 Ceph， 然 后 才能 使 用 RBD 。 


RBD 的 一 个 特点 是 它 可 以 同时 为 多 个 用 户 以 只 读 方式 挂 载 。 这 意味 着 可 以 预先 使 用 
您 的 数据 集 填充 卷 ， 然 后 根据 需要 同时 为 多 个 pod 并 行 提 供 。 不 幸 的 是 ，RBD & 
只 能 由 单个 用 户 以 读 写 模式 安装 不 允许 同时 写 入 





有 关 更 多 详细 信息 ， 请 参阅 RBD 示 例 。 


scalelO 


ScalelO 是 一 个 基于 软件 的 存储 平台 ， 可 以 使 用 现 有 的 硬件 来 创建 可 扩展 的 共享 块 
网 络 存 储 集群 。 scaleI0 卷 插件 允许 已 部 署 的 pod 访问 现 有 的 ScalelO & (或 
者 它 可 以 为 持久 性 卷 声 明 动 态 调配 新 卷 ， 请 参阅 ScalelO 持久 卷 ) e 


重要 提示 : 您 必须 有 一 个 已 经 配置 好 的 ScalelO 集群 ， 并 和 创建 的 卷 一 同 运行 
后 才能 使 用 它们 。 


以 下 是 使 用 ScalelO 的 示例 pod 配置 


apiVersion: v1 
kind: Pod 
metadata: 
name: pod-0 
spec: 
containers: 
- image: k8s.gcr.io/test-webserver 
name: pod-0 
volumeMounts: 
- mountPath: /test-pd 
name: vol-0 
volumes: 
- name: vol-0 
scaleIO: 
gateway: https://localhost:443/api 
system: scaleio 
protectionDomain: sdO 
storagePool: sp1 
volumeName: vol-0 


secretRef: 
name: sio-secret 
fsType: xfs 


有 关 更 多 详细 信息 ， 请 参阅 ScalelO 示例 。 


Secret 


secret 卷 用 于 将 敏感 信息 (如 密码 ) 传递 到 pod。 您 可 以 将 secret 存储 在 
Kubernetes API 中 ， 并 将 它们 挂 载 为 文件 ， 以 供 Pod 使 用 ， 而 无 需 直 接连 接 到 
Kubernetes。 secret 卷 由 tmpfs (一 个 RAM 支持 的 文件 系统 ) 支持 ， 所 以 它 
们 永远 不 会 写 入 非 易 失 性 存储 器 。 


重要 提示 : 您 必须 先 在 Kubernetes API 中 创建 一 个 secret， 然 后 才能 使 用 它 。 


Secret 在 这 里 被 更 详细 地 描述 。 


storageOS 


storageos 卷 允 许 将 现 有 的 StorageOS 卷 挂 载 到 容器 中 。 


StorageOS 在 Kubernetes 环境 中 以 容器 方式 运行 ， 使 本 地 或 附加 存储 可 以 从 
Kubernetes 集群 中 的 任何 节点 访问 。 可 以 复制 数据 以 防止 节点 故障 。 精 简 配置 和 压 
缩 可 以 提高 利用 率 并 降低 成 本 。 

StorageOS 的 核心 是 为 容器 提供 块 存储 ， 可 以 通过 文件 系统 访问 。 

StorageOS 容器 需要 64 位 Linux， 没 有 额外 的 依赖 关系 。 可 以 使 用 免费 的 开发 者 
许可 十 。 


重要 提示 : 您 J 问 StorageOS 卷 的 节点 上 运行 StorageOS 容器 ， 或 
者 为 该 池 提 供 存 储 容量 。 相 关 的 安装 说 明 ， 请 参阅 StorageOS x 43 o 


apiVersion: v1 
kind: Pod 
metadata: 
labels: 
name: redis 
role: master 
name: test-storageos-redis 
spec: 
containers: 
- name: master 
image: kubernetes/redis:vi 
env: 
- name: MASTER 
value: "true" 
ports: 
- containerPort: 6379 
volumeMounts: 
- mountPath: /redis-master-data 
name: redis-data 
volumes: 
- name: redis-data 
storageos: 
# The ^redis-volO1^ volume must already exist within Sto 
rageOS in the "default" namespace. 
volumeName: redis-vol01 
fsType: ext4 


有 关 更 多 信息 ， 包 括 动 态 配置 和 持久 化 卷 声明 ， 请 参阅 StorageOS 示例 。 


vsphereVolume 


先决 条 件 : 配置 了 vSphere Cloud Provider 的 Kubernetes。 有 关 云 提供 商 的 配 
置 ， 请 参阅 vSphere 入 门 指南 。 


vsphereVolume 用 于 将 vSphere VMDK 卷 挂 载 到 Pod P ° 4H A RE HRA 
被 保留 。 支 持 VMFS f» VSAN 数据 存储 。 


重要 提示 : 在 Pod 中 使 用 它 之 前 ， 您 必须 使 用 以 下 一 种 方法 创建 VMDK © 
创建 VMDK 卷 
选择 以 下 方法 之 一 来 创建 VMDK 。 


首先 进入 ESX， 然 后 使 用 以 下 命令 创建 一 个 VMDK : 


vmkfstools -c 2G /vmfs/volumes/DatastoreName/volumes/myDisk.vmdk 


使 用 下 列 命令 创建 一 个 VMDK : 


vmware-vdiskmanager -c -t © -s 40GB -a lsilogic myDisk.vmdk 


vSphere VMDK 示例 配置 


apiVersion: v1 
kind: Pod 
metadata: 
name: test-vmdk 
spec: 
containers: 
- image: k8s.gcr.io/test-webserver 
name: test-container 
volumeMounts: 
- mountPath: /test-vmdk 
name: test-volume 
volumes: 
- name: test-volume 
# This VMDK volume must already exist. 
vsphereVolume: 
volumePath: "[DatastoreName] volumes/myDisk" 
fsType: ext4 


更 多 的 例子 可 以 在 这 里 找到 。 


使 用 subPath 


有 时 ， 在 单个 容器 中 共享 一 个 卷 用 于 多 个 用 途 是 有 用 
的 。 volumeMounts.subPath 属性 可 用 于 在 引用 的 卷 内 而 不 是 其 根 目 录 中 指定 子 
路 径 。 


下 面 是 一 个 使 用 单个 共享 卷 的 LAMP 324% (Linux Apache Mysql PHP) 的 示例 。 
HTML 内 容 被 映射 到 它 的 html 目录 ， 数 据 库 将 被 存储 在 它 的 mysql 目录 中 : 


apiVersion: v1 
kind: Pod 
metadata: 
name: my-lamp-site 
spec: 
containers: 
- name: mysql 
image: mysql 
env: 
- name: MYSQL_ROOT_PASSWORD 
value: "rootpasswd" 
volumeMounts: 
- mountPath: /var/lib/mysql 
name: site-data 
subPath: mysql 
name: php 
image: php:7.0-apache 
volumeMounts: 
- mountPath: /var/www/html 
name: site-data 
subPath: html 
volumes: 
- name: site-data 
persistentVolumeClaim: 
claimName: my-lamp-site-data 


emptyDir 卷 的 存储 介质 (MR ` SSD +) 由 保存 在 kubelet 根 目录 的 文件 系统 
的 介质 (通常 是 /var/lib/kubelet ) 决定 。 emptyDir 或 hostPath 卷 可 
占用 多 少 空间 并 没有 限制 ， 容 器 之 间或 Pod 之 间 也 没有 隔离 。 


在 将 来 ， 我 们 预计 emptyDir 和 hostPath 卷 将 能 够 使 用 resource 规范 请 求 一 
定 的 空间 ， 并 选择 要 使 用 的 介质 ， 适 用 于 具有 多 种 媒体 类 型 的 集群 。 


Out-of-Tree #4644 


除了 之 前 列 出 的 卷 类 型 之 外 ， 存 储 供应 商 可 以 创建 自 定 义 插件 而 不 将 其 添加 到 
Kubernetes 存储 库 中 。 可 以 通过 使 用 FlexVolume 插件 来 实现 。 


FlexVolume 使 用 户 能 够 将 供应 商 卷 挂 载 到 容器 中 。 供 应 商 插件 是 使 用 驱动 程序 
实现 的 ， 该 驱动 程序 支持 由 Flexvolume API 定 义 的 一 系列 卷 命 令 。 驱 动 程 序 必 
须 安 装 在 每 个 节点 的 预定 义 卷 插件 路 径 中 。 


更 多 细节 可 以 在 这 里 找到 。 


挂 载 传播 
注意 : 挂 载 传播 是 Kubernetes 1.8 中 的 一 个 alpha 特性 ， 在 将 来 的 版 本 中 可 能 会 重 
新 设计 甚至 删除 。 


挂 载 传播 允许 将 由 容器 挂 载 的 卷 共 享 到 同一 个 Pod 中 的 其 他 容器 上 ， 甚 至 是 同一 节 
点 上 的 其 他 Pod 。 


ww. 


如 果 禁 用 MountPropagation 功能 ， 则 不 会 传播 pod 中 的 卷 挂 载 。 也 就 是 说 ， 容 器 
按照 Linux 内 核 文档 中 所 述 的 private 挂 载 传播 运行 。 


要 局 用 此 功能 ， 请 在 --feature-gates 命令 行 选项 中 指定 MountPropagation 
= true 。 启 用 时 ， 容 器 的 volumeMounts 字段 有 一 个 新 的 
mountPropagation 子 字段 。 它 的 值 为 : 


e HostToContainer : 此 卷 挂 载 将 接收 所 有 后 续 挂 载 到 此 卷 或 其 任何 子 目录 的 
挂 载 。 这 是 MountPropagation 功能 启用 时 的 默认 模式 。 


同样 的 ， 如 果 任 何 带 有 Bidirectional 挂 载 传播 的 pod 挂 载 到 同一 个 卷 
上 ， 带 有 HostToContainer 挂 载 传 播 的 容器 将 会 看 到 它 。 


该 模式 等 同 于 Linux 内 核 文 档 中 描述 的 rslave 挂 载 传播 。 


e Bidirectional 卷 挂 载 与 HostToContainer 挂 载 相 同 。 另 外 ， 由 容器 创 
建 的 所 有 卷 挂 载 将 被 传播 回 主机 和 所 有 使 用 相同 卷 的 容器 ， M ° 


此 模式 的 一 个 典型 用 例 是 带 有 Flex 卷 驱 动 器 或 需要 使 用 HostPath 卷 在 主机 上 
挂 载 某 些 内 容 的 pod。 


该 模式 等 同 于 Linux 内 核 文档 中 所 述 的 rshared 挂 载 传播 。 


小 心 : 双向 挂 载 传播 可 能 是 危险 的 。 它 可 能 会 损坏 主机 操作 系统 ， 因 此 只 能 在 特权 
容器 中 使 用 。 强 烈 建议 熟悉 Linux 内 核 行为 。 另 外 ， 容 器 在 Pod 中 创建 的 任何 卷 挂 
载 必须 在 容器 终止 时 销毁 (PR) 。 


e https://kubernetes.io/docs/concepts/storage/volumes/ 


e 使 用 持久 化 卷 来 部 署 WordPress 和 MySQL 
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Persistent Volume (持久 化 卷 ) 


本 文档 介绍 了 Kubernetes 中 PersistentVolume 的 当前 状态 。 建 议 您 在 阅读 本 
文档 前 先 熟 悉 volume © 


介绍 


对 于 管理 计算 资源 来 说 ， 管理 存储 资源 明显 是 另 一 个 问题 。 Persistentvolume 
子 系统 为 用 户 和 管理 员 提供 了 一 个 API， 该 API 将 如 何 提供 存储 的 细节 抽象 了 出 
来 。 为 此 ， 我 们 引入 两 个 新 的 API 资源 : PersistentVolume 和 


PersistentVolumeClaim ° 


PersistentVolume (PV) 是 由 管理 员 设 置 的 存储 ， 它 是 群集 的 一 部 分 。 就 像 节 
点 是 集群 中 的 资源 一 样 ，PV 也 是 集群 中 的 资源 。PV 是 Volume 之 类 的 卷 插件 ， 但 
具有 独立 于 使 用 PV 的 Pod 的 生命 周期 。 此 API 对 象 包含 存 储 实现 的 细节 ， 即 
NFS ^ iSCSI 或 特定 于 云 供应 商 的 存储 系统 。 


PersistentVolumeClaim (PVC) 是 用 户 存 储 的 请 求 。 它 与 Pod 相似 。Pod 消 
耗 节点 资源 ，PVC 消耗 PV 资源 。Pod 可 以 请 求 特定 级 别 的 资源 (CPU 和 内 

存 ) 。 声 明 可 以 请 求 特定 的 大 小 和 访问 模式 (例如 ， 可 以 以 读 / 写 一 次 或 只 读 多 次 
ERNER) ° 

虽然 PersistentVolumeClaims 允许 用 户 使 用 抽象 存储 资源 ， 但 用 户 需 要 具有 不 
同性 质 (例如 性 能 ) 的 PersistentVolume 来 解决 不 同 的 问题 。 集 群 管理 员 需 
能 够 提供 各 种 各 样 的 PersistentVvolume ， 这 些 PersistentVolume 的 大 小 和 
访问 模式 可 以 各 有 不 同 ， 但 不 需要 向 用 户 公开 实现 这 些 卷 的 细节 。 对 于 这 些 需 

求 ，StorageClass 资源 可 以 实现 。 


请 参阅 工作 示例 的 详细 过 程 。 


卷 和 声明 的 生命 周期 


PV 属于 集群 中 的 资源 。PVC 是 对 这 些 资 源 的 请 求 ， 也 作为 对 资源 的 请 求 的 检查 。 
PV 和 PVC 之 间 的 相互 作用 遵循 这 样 的 生命 周期 : 


配置 (Provision) 


有 两 种 方式 来 配置 PV : 静态 或 动态 。 


静态 


集群 管理 员 创建 一 些 PV。 它 们 带 有 可 供 群集 用 户 使 用 的 实际 存储 的 细节 。 它 们 存 
在 于 Kubernetes API 中 ， 可 用 于 消费 。 


当 管 理 员 创建 的 静态 PV 都 不 匹配 用 户 的 PersistentVolumeClaim 时 ， 集 群 可 
能 会 党 试 动 态 地 为 PVC 创建 卷 。 此 配置 基于 storageclasses : PVC 必须 请 求 
存储 类 ， 并 且 管 理 员 必须 创建 并 配置 该 类 才能 进行 动态 创建 。 声 明 该 类 为 "" 可 
以 有 效 地 禁用 其 动态 配置 


要 启用 基于 存储 级 别 的 动态 存储 配置 ， 集 群 管理 员 需 要 启用 API server 上 的 
DefaultStorageClass 准 入 控制 回 。 例 如 ， 通 过 确保 DefaultStorageClass 
位 于 API server 2274 --admission-control 标志 ， 使 用 逗号 分 隔 的 有 序 值 列 
表 中 ， 可 以 完成 此 操作 。 有 关 API server 命令 行 标志 的 更 多 信息 ， 请 检查 kube- 

apiserver 文档 。 


BB 


再 动态 配置 的 情况 下 ， 用 户 创建 或 已 经 创建 了 具有 特定 存储 量 的 
PersistentVolumeClaim 以 及 某 些 访问 模式 。master 中 的 控制 环 路 监视 新 的 

PVC， 了 寻找 匹配 的 PV (如 果 可 能 ) ， 并 将 它们 绑 定 在 一 起 。 如 果 为 新 的 PVC 动态 

调配 PV， 则 该 环 路 将 始终 将 该 PV 绑 定 到 PVC。 否 则 ， 用 户 总 会 得 到 他 们 所 请 求 
的 存储 ， 但 是 容量 可 能 超出 要 求 的 数量 。 一 旦 PV 和 PVC RE 

后 ，PersistentVolumeClaim 绑 定 是 排他 性 的 ， 不 管 它们 是 如 何 绑 定 的 。 PVC 

IR PV 绑 定 是 一 对 一 的 映射 。 


果 没 有 匹配 的 卷 ， 声 明 将 无 限期 地 保持 未 绑 定 状态 。 随 着 匹配 卷 的 可 用 ， 声 
ae 例如 ， 配 置 了 许多 50Gi PV 的 集群 将 不 会 匹配 请 求 100Gi 4 PVC ° 
100Gi PV 添加 到 群集 时 ， 可 以 绑 定 PVC © 


使 用 


Pod 使 用 声明 作为 卷 。 集 群 检查 声明 以 查找 绑 定 的 卷 并 为 集群 挂 载 该 卷 。 对 于 支持 
多 种 访问 模式 的 卷 ， 用 户 指 定 在 使 用 声明 作为 容器 中 的 卷 时 所 需 的 模式 。 


用 户 进行 了 声明 ， 并 且 该 声明 是 绑 定 的 ， 则 只 要 用 户 需 要 ， 绑 定 的 PV 就 属于 该 用 
户 。 用 户 通过 在 Pod 的 volume 配置 中 包含 persistentVolumeClaim 来 调度 
Pod 并 访问 用 户 声明 的 PV。 请 参阅 下 面 的 语法 细节 。 


持久 化 卷 声明 的 保护 


PVC 保护 的 目的 是 确保 由 pod 正在 使 用 的 PVC 不 会 从 系统 中 移 除 ， 因 为 如 果 被 移 
除 的 话 可 能 会 导致 数据 丢失 。 


注意 : 当 pod 状态 为 Pending ŽE pod 已 经 分 配给 节点 或 pod 为 Running X 
态 时 ，PVC 处 于 活动 状态 。 


当局 用 PVC 保护 alpha 功能 时 ， 如 果 用 户 删 除了 一 个 pod 正在 使 用 的 PVC > ME 
PVC 不 会 被 立即 删除 。PVC 的 删除 将 被 推迟 ， 直 到 PVC 不 再 被 任何 pod 使 用 。 


您 可 以 看 到 ， 当 PVC 的 状态 为 Teminatiing 时 ，PVC 受到 保 


护 ，Finalizers 列表 中 包含 kubernetes.io/pvc-protection 


kubectl described pvc hostpath 


Name: hostpath 

Namespace: default 

StorageClass:  example-hostpath 

Status: Terminating 

Volume: 

Labels: «none» 

Annotations: volume.beta.kubernetes.io/storage-class-example-h 
ostpath 


volume.beta.kubernetes.io/storage-provisioner-exa 
mple.com/hostpath 
Finalizers: [kubernetes.io/pvc-protection] 


回收 


用 户 用 完 volume 后 ， 可 以 从 允许 回收 资源 的 APL 中 删除 PVC 对 
象 。 PersistentVolume 的 回收 策略 告诉 集群 在 存储 卷 声明 释放 后 应 如 何 处 理 该 
Æ o AAT > volume 的 处 理 策 略 有 保留 、 回 收 或 删除 。 


保留 


保留 回收 策略 允许 手动 回收 资源 。 当 PersistentVolumeClaim 被 删除 

时 ， PersistentVolume RÆ > volume 被 视 为 “已 释放 ”。 但 是 由 于 前 一 个 声 
明 人 的 数据 仍然 存在 ， 所 以 还 不 能 马上 进行 其 他 声明 。 管 理 员 可 以 通过 以 下 步 又 
动 回收 卷 。 


1. 删除 PersistentVolume 。 在 删除 PV 后 ， 外 部 基础 架构 中 的 关联 存储 资产 
(如 AWS EBS ` GCE PD ` Azure Disk 或 Cinder #) 仍然 存在 。 

2. 手动 清理 相关 存储 资产 上 的 数据 。 

3. 手动 删除 关联 的 存储 资产 ， 或 者 如 果 要 重新 使 用 相同 的 存储 资产 ， 请 使 用 存储 
资产 定义 创建 新 的 PersistentVolume 。 


回收 


如 果 存 储 卷 插件 支持 ， 回 收 策 略 会 在 volume 上 执行 基本 擦 除 ( rm -rf / 
thevolume / * ) ， 可 被 再 次 声明 使 用 。 


但 是 ， 管 理 员 可 以 使 用 如 此 处 所 述 的 Kubernetes controller manager 命令 行 参数 来 
配置 自 定义 回 收 站 pod 模板 。 自 定义 回收 站 pod 模板 必须 包含 volumes 规范 ， 
如 下 面 的 示例 所 示 : 


apiVersion: v1 
kind: Pod 
metadata: 
name: pv-recycler 
namespace: default 
spec: 
restartPolicy: Never 
volumes: 
- name: vol 
hostPath: 
path: /any/path/it/will/be/replaced 
containers: 
- name: pv-recycler 
image: "k8s.gcr.io/busybox" 
command: ["/bin/sh", "-c", "test -e /scrub && rm -rf /scrub/ 
..?* /scrub/.[!.]* /scrub/* && test -z N'$(l1s -A /scrub)\" || e 
xit 1"] 
volumeMounts: 
- name: vol 
mountPath: /scrub 


但 是 ， volumes 部 分 的 自 定义 回收 站 模块 中 指定 的 特定 路 径 将 被 蔡 换 为 正在 回收 
的 卷 的 特定 路 径 。 


对 于 支持 删除 回收 策略 的 卷 插 件 ， 删 除 操 作 将 从 Kubernetes 中 删除 
PersistentVolume 对 象 ， 并 删除 外 部 基础 架构 (如 AWS EBS ` GCE PD ` 
Azure Disk 或 Cinder #) 中 的 关联 存储 资产 。 动 态 配置 的 卷 继承 其 
StorageClass 的 回收 策略 ， 默 认为 Delete。 管 理 员 应 该 根据 用 户 的 期 望 来 配置 
StorageClass ， 否 则 就 必须 要 在 PV 创建 后 进行 编辑 或 修补 。 请 参阅 更 改 
PersistentVolume 的 回收 策略 。 


扩展 持久 化 卷 声明 


Kubernetes 1.8 增加 了 对 扩展 持久 化 存储 卷 的 Alpha 支持 。 在 v1.9 中 ， 以 下 持久 
化 卷 支持 扩展 持久 化 卷 声明 : 


e gcePersistentDisk 

e awsElasticBlockStore 
e Cinder 

e glusterfs 

e rbd 


管理 员 可 以 通过 将 ExpandPersistentvolumes 特性 门 设 置 为 true 来 允许 扩展 持 
久 卷 声明 。 管 理 员 还 应 该 启用 PersistentVolumeClaimResize 准 入 控制 插件 来 
执行 对 可 调整 大 小 的 卷 的 其 他 验证 。 


一 旦 PersistentVolumeClaimResize 准 入 插件 已 打开 ， 将 只 允许 其 
allowVolumeExpansion 字段 设置 为 true 的 存储 类 进行 大 小 调整 。 


kind: StorageClass 
apiVersion: storage.k8s.io/vi 
metadata: 

name: gluster-vol-default 
provisioner: kubernetes.io/glusterfs 
parameters: 

resturl: "http://192.168.10.100:8080" 

restuser: "" 

secretNamespace: "" 

secretName: "" 
allowvolumeExpansion: true 


一 旦 功能 门 和 前 述 准 入 插件 打开 后 ， 用 户 就 可 以 通过 简单 地 编辑 声明 以 请 求 更 大 的 
PersistentVolumeClaim 卷 。 这 反 过 来 将 触发 PersistentVolume 后 端的 卷 

扩展 。 

在 任何 情况 下 都 不 会 创建 新 的 PersistentVolume 来 满足 声明 。Kubernetes 将 

尝试 调整 现 有 volume 来 满足 声明 的 要 求 。 


对 于 扩展 包含 文件 系统 的 卷 ， 只 有 在 ReadWrite 模式 下 使 用 
PersistentVolumeClaim 启动 新 的 Pod 时 ， 才 会 执行 文件 系统 调整 大 小 。 换 名 
话说 ， 如 果 正 在 扩展 的 卷 在 pod 或 部 署 中 使 用 ， 则 需要 删除 并 重新 创建 要 进行 文件 

系统 调整 大 小 的 pod。 此 外 ， 文 件 系 统 调整 大 小 仅 适 用 于 以 下 文件 系统 类 型 : 


e XFS 
e Ext3 ^ Ext4 


注意 : 扩展 EBS 卷 是 一 个 耗 时 的 操作 。 另 外 ， 每 6 个 小 时 有 一 个 修改 养 的 配额 。 


持久 化 卷 类 型 
PersistentVolume 类 型 以 插件 形式 实现 。Kubernetes 目前 支持 以 下 插件 类 型 : 


e GCEPersistentDisk 

e AWSElasticBlockStore 

e AzureFile 

e AzureDisk 

e FC (Fibre Channel) 

e FlexVolume 

e Flocker 

e NFS 

e iSCSI 

e RBD (Ceph Block Device) 

e CephFS 

e Cinder (OpenStack block storage) 

e Glusterfs 

e VsphereVolume 

e Quobyte Volumes 

e HostPath ( 仅 限 于 但 节点 测试 
多 节点 集群 中 工作 ) 


不 会 以 任何 方式 支持 本 地 存储 ， 也 无 法 在 





e VMware Photon 

e Portworx Volumes 
e ScalelO Volumes 
e StorageOS 


原始 块 支持 仅 适 用 于 以 上 这 些 插件 。 


持久 化 卷 
每 个 PV 配置 中 都 包含 一 个 sepc 规格 字段 和 一 个 status 卷 状态 字段 。 


apiVersion: v1 
kind: PersistentVolume 
metadata: 
name: pVv0003 
spec: 
Capacity: 

storage: 5Gi 
volumeMode: Filesystem 
accessModes: 

- ReadwriteOnce 
persistentVolumeReclaimPolicy: Recycle 
storageClassName: slow 
mountOptions: 

- hard 

- nfsvers-4.1 
nfs: 

path: /tmp 

server: 172.17.0.2 


` 
ON 


AY 


halo 


通常 ，PV 将 具有 特定 的 存储 容量 。 这 是 使 用 PV 的 容量 属性 设置 的 。 查 看 
Kubernetes 资源 模型 以 了 解 capacity 预期 。 


目 


a 


， 存储 大 小 是 可 以 设置 或 请 求 的 唯一 资源 。 未 来 的 属性 可 能 包括 IOPS ^ Bek 


o 


前 


网 


HARK, 


在 v1.9 之 前 ， 所 有 卷 插件 的 默认 行为 是 在 持久 卷 上 创建 一 个 文件 系统 。 在 v1.9 
中 ， 用 户 可 以 指定 一 个 volumeMode， 除 了 文件 系统 之 外 ， 它 现在 将 支持 原始 块 设 
& » volumeMode 的 有 效 值 可 以 是 “Filesystem” 或 “Block”。 如 果 未 指定 ， 
volumeMode 将 默认 为 “Filesystem”。 这 是 一 个 可 选 的 API 参数 。 


注意 : 该 功能 在 V1.9 中 是 alpha 的 ， 未 来 可 能 会 更 改 。 
访问 模式 


PersistentVolume 可 以 以 资源 提供 者 支持 的 任何 方式 挂 载 到 主机 上 。 如 下 表 所 

示 ， 供 应 商 具 有 不 同 的 功能 ， 每 个 PV 的 访问 模式 都 将 被 设置 为 该 卷 支持 的 特定 模 
式 。 例 如 ，NFS 可 以 支持 多 个 读 / 写 客户 端 ， 但 特定 的 NFS PV 可 能 以 只 读 方式 导 
出 到 服务 器 上 。 每 个 PV 都 有 一 套 自 己 的 用 来 描述 特定 功能 的 访问 模式 。 


存储 模式 包括 : 





e ReadWriteOnce 
e ReadOnlyMany 
e ReadWriteMany 


该 卷 可 以 被 单个 节点 以 读 / 写 模式 挂 载 
该 卷 可 以 被 多 个 节点 以 只 读 模式 挂 载 
该 卷 可 以 被 多 个 节点 以 读 / 写 模式 挂 载 








在 命令 行 中 ， 访 问 模式 缩写 为 : 


e RWO - ReadWriteOnce 
e ROX - ReadOnlyMany 
e RWX - ReadWriteMany 


重要 ! 一 个 卷 一 次 只 能 使 用 一 种 访问 模式 挂 载 ， 即 使 它 支持 很 多 访问 模式 。 例 
如 ，GCEPersistentDisk 可 以 由 单个 节点 作为 ReadWriteOnce HAIER? RW 
多 个 节点 以 ReadOnlyMany 模式 挂 载 ， 但 不 能 同时 挂 载 。 


ReadWriteOnce 


Volume 插件 

AWSElasticBlockStore V 
AzureFile "4 
AzureDisk "4 
CephFS vi 
Cinder "A 
FC "4 
FlexVolume V 
Flocker v 
GCEPersistentDisk J 
Glusterfs / 
HostPath V 
iSCSI Z 
PhotonPersistentDisk V 
Quobyte v 
NFS / 
RBD v 
VsphereVolume V 
PortworxVolume V 
ScalelO "4 
StorageOS V 

X 


ReadOnlyMany 


V 


V 


V 


V 


ReadWriteMa 


PV 可 以 具有 一 个 类 ， 通 过 将 storageClassName 属性 设置 为 StorageClass 的 名 
称 来 指定 该 类 。 一 个 特定 类 别 的 PV 只 能 绑 定 到 请 求 该 类 别 的 PVC » AUR 
storageClassName 的 PV 就 没有 类 ， 它 只 能 绑 定 到 不 需要 特定 类 的 PVC。 


过 去 ， 使 用 的 是 volume.beta.kubernetes.io/storage-class 注解 而 不 是 
storageClassName 属性 。 这 个 注解 仍然 有 效 ， 但 是 将 来 的 Kubernetes 版 本 中 


将 会 完全 弃 用 它 。 


回收 策略 


当前 的 回收 策略 包括 : 


Retain (48 @ ) 一 一 手动 回收 

Recycle (回收 ) 一 一 基本 擦 除 ( rm -rf /thevolume/* ) 

Delete (MR) 一 一 关联 的 存储 资产 (例如 AWS EBS ` GCE PD ` Azure Disk 
和 OpenStack Cinder 卷 ) 将 被 删除 


当前 ， 只 有 NFS 和 HostPath 支持 回收 策略 。AWS EBS ` GCE PD ` Azure Disk 
和 Cinder 卷 支持 删除 策略 。 


挂 载 选项 


Kubernetes 管理 员 可 以 指定 在 节点 上 为 挂 载 持 久 卷 指定 挂 载 选 项 。 


注意 : 不 是 所 有 的 持久 化 卷 类 型 都 支持 挂 载 选项 。 


以 下 卷 类 型 支持 挂 载 选项 : 


GCEPersistentDisk 
AWSElasticBlockStore 
AzureFile 

AzureDisk 

NFS 

iSCSI 

RBD (Ceph Block Device) 
CephFS 

Cinder (OpenStack & 4 fik ) 
Glusterfs 

VsphereVolume 

Quobyte Volumes 

VMware Photon 


挂 载 选 项 没有 校 验 ， 如 果 挂 载 选 项 无 效 则 挂 载 失败 。 


过 去 ， 使 用 volume.beta.kubernetes.io/mount-options 注解 而 不 是 
mountOptions 属性 。 这 个 注解 仍然 有 效 ， 但 在 将 来 的 Kubernetes 版 本 中 它 将 


会 被 完全 弃 用 。 


状态 
卷 可 以 处 于 以 下 的 某 种 状态 : 


e Available (可 用 ) 一 一 一 块 空闲 资源 还 没有 被 任何 声明 绑 定 

e Bound (CRE) 一 一 卷 已 经 被 声明 绑 定 

e Released (已 释放 ) 一 一 声明 被 删除 ， 但 是 资源 还 未 被 集群 重新 声明 
e Failed (AK) 该 卷 的 自动 回收 失败 





命令 行 会 显示 绑 定 到 PV 的 PVC 的 名 称 。 


PersistentVolumeClaim 
#& PVC 中 都 包含 一 个 spec 规格 字段 和 一 个 status 声明 状态 字段 。 


kind: PersistentVolumeClaim 
apiVersion: vi 
metadata: 
name: myclaim 
spec: 
accessModes: 

- ReadwriteOnce 
volumeMode: Filesystem 
resources: 

requests: 

storage: 8Gi 
storageClassName: slow 
selector: 

matchLabels: 

release: "stable" 

matchExpressions: 

- (key: environment, operator: In, values: [dev]) 


访问 模式 
在 请 求 具有 特定 访问 模式 的 存储 时 ， 声 明 使 用 与 卷 相同 的 约定 。 


AAR HA 


声明 使 用 与 卷 相 同 的 约定 ， 指 示 将 卷 作 为 文件 系统 或 块 设备 使 用 。 


资源 


像 pod 一 样 ， 声 明 可 以 请 求 特定 数量 的 资源 。 在 这 种 情况 下 ， 请 求 是 用 于 存储 的 。 
相同 的 资源 模型 适用 于 卷 和 声明 。 


t4 & 


声明 可 以 指定 一 个 标签 选择 器 来 
省 器 由 两 个 字 


进一步 过 滤 该 组 卷 。 只 有 标签 与 选择 器 匹配 的 卷 可 
以 绑 定 到 声明 。 选 择 XA: 


e matchLabels : volume 必须 有 具有 该 值 的 标签 

e matchExpressions : 这 是 一 个 要 求 列 表 ， 通 过 指定 关键 字 ， 值 列表 以 及 与 关键 
字 和 值 相 关 的 运算 符 组 成 。 有 效 的 运算 符 包 括 In、Notln、Exists 和 
DoesNotExist ° 


所 有 来 自 matchLabels 和 matchExpressions 的 要 求 都 被 “与 "在 一 
必须 全 部 满足 才能 匹配 。 





类 

声明 可 以 通过 使 用 属性 storageClassName 指定 StorageClass 的 名 称 来 请 求 特 
定 的 类 。 只 有 所 请 求 的 类 与 PVC 具有 相同 storageClassName 的 PV 才能 绑 定 
到 PVC » 


PVC 不 一 定 要 请 求 类 。 storageClassName 设置 为 " 的 PVC 始终 被 解释 
为 没有 请 求 类 的 PV ， "e EREI AA X PV (没有 注解 或 ""o) o9 RA 
storageClassName fj PVC 根据 是 否 打 开 DefaultStorageClass 准 入 控制 插 
件 ， 集 群 对 其 进行 不 同 处 理 。 


e 如 果 打 开 了 准 入 控制 插件 ， 管 理 员 可 以 指定 一 个 默认 的 StorageClass 。 所 
有 没有 storageclassName 的 PVC 将 被 绑 定 到 该 默认 的 PV。 通 过 在 
StorageClass 对 象 中 将 注解 storageclassclass.ubernetes.io/is- 
default-class 设置 为 “true” 来 指定 默认 的 StorageClass 。 如 果 管 理 员 
没有 指定 缺 省 值 ， 那 么 集群 会 响应 PVC 创建 ， 就 好 像 关 闭 了 准 入 控制 插件 一 
样 。 如 果 指 定 了 多 个 默认 值 ， 则 准 入 控制 插件 将 禁止 所 有 PVC 创建 。 
e 如 果 准 入 控制 插件 被 关闭 ， 则 没有 默认 StorageClass 的 概念 。 所 有 没有 
storageClassName 的 PVC 只 能 绑 定 到 没有 类 的 PV。 在 这 种 情况 下 ， 没 有 
storageClassName 的 PVC 的 处 理 方式 与 storageClassName 设置 为 


"" 的 PVC 的 处 理 方式 相同 。 


根据 安装 方法 的 不 同 ， 默 认 的 StorageClass 可 以 在 安装 过 程 中 通过 插件 管理 器 
部 署 到 Kubernetes 集群 。 


3 PVC 指定 了 selector ， 除 了 请 求 一 个 StorageClass 之 外 ， 这 些 需求 
被 "与 "在 一 起 : 只 有 被 请 求 的 类 的 PV 具有 和 被 请 求 的 标签 才 可 以 被 绑 定 到 PVC 。 


注意 : 目前 ， 具 有 非 空 selector 的 PVC 不 能 为 其 动态 配置 PV。 


过 去 ， 使 用 注解 volume.beta.kubernetes.io/storage-class 而 不 是 
storageClassName 属性 。 这 个 注解 仍然 有 效 ， 但 是 在 未 来 的 Kubernetes 版 本 
中 不 会 支持 。 


声明 作为 郑 


通过 将 声明 用 作 卷 来 访问 存储 。 声 明 必 须 与 使 用 声明 的 pod 存在 于 相同 的 命名 空间 
中 。 集 群 在 pod 的 命名 宝 间 中 查找 声明 ， 并 使 用 它 来 获取 支持 声明 的 
PersistentVolume 。 该 卷 然后 被 挂 载 到 主机 的 pod 上 。 


kind: Pod 
apiVersion: vi 
metadata: 
name: mypod 
spec: 
containers: 
- name: myfrontend 
image: dockerfile/nginx 
volumeMounts: 
- mountPath: "/var/www/html" 
name: mypd 
volumes: 
- name: mypd 
persistentVolumeClaim: 
claimName: myclaim 


命名 空间 注意 点 

PersistentVolumes 绑 定 是 唯一 的 ， 并 且 由 于 PersistentVolumeClaims Æ 
命名 空间 对 象 ， 因 此 只 能 在 一 个 命名 空间 内 挂 载 具 有 "多 个 "模式 ( ROX RWX ) 
的 声明 。 


原始 块 卷 支 持 


原始 块 卷 的 静态 配置 在 v1.9 中 作为 alpha 功能 引入 。 由 于 这 个 改变 ， 需 要 一 些 新 
的 API 字段 来 使 用 该 功能 。 目 前 ，Fibre Channl 是 支持 该 功能 的 唯一 插件 。 


使 用 原始 块 卷 作为 持久 化 疮 


apiVersion: v1 
kind: PersistentVolume 
metadata: 
name: block-pv 
spec: 
Capacity: 
storage: 10Gi 
accessModes: 
- ReadwriteOnce 
volumeMode: Block 
persistentVolumeReclaimPolicy: Retain 
fc: 
targetWWNs: ["50060e801049cfd1"] 
lun: 0 
readOnly: false 


持久 化 卷 声明 请 求 原始 块 卷 


apiVersion: vi 
kind: PersistentVolumeClaim 
metadata: 
name: block-pvc 
spec: 
accessModes: 

- ReadwriteOnce 
volumeMode: Block 
resources: 

requests: 

storage: 10Gi 


在 Pod 规格 配置 中 为 容器 添加 原始 块 设 备 


apiVersion: v1 
kind: Pod 
metadata: 
name: pod-with-block-volume 
spec: 
containers: 
- name: fc-container 
image: fedora:26 
command: ["/bin/sh", "-c"] 
args: [ "tail -f /dev/null" ] 
volumeDevices: 
- name: data 
devicePath: /dev/xvda 
volumes: 
- name: data 
persistentVolumeClaim: 
claimName: block-pvc 


注意 : SA Pod 增加 原始 块 设 备 时 ， 我 们 在 容器 中 指定 设备 路 径 而 不 是 挂 载 路 径 。 


BB R Eo: 


如 果 用 户 通 过 使 用 persistentVolumeClaim 规范 中 的 volumeMode 字段 指示 
此 请 求 来 请 求 原始 块 卷 ， 则 绑 定 规则 与 以 前 不 认为 该 模式 为 规范 一 部 分 的 版 本 略 有 
不 同 。 


下 面 是 用 户 和 管理 员 指 定 请 求 原 始 块 设备 的 可 能 组 合 的 表格 。 该 表 指 示 卷 是 否 将 被 
Dp RAB BA o HALEY AM EEE: 


PV volumeMode PVC volumeMode 结果 
unspecified unspecified Ap 
unspecified Block TRE 
unspecified Filesystem Ap 
Block unspecified FR GB 
Block Block BB 
Block Filesystem FR GB 
Filesystem Filesystem BB d 
Filesystem Block TRE 
Filesystem unspecified zy d 


: alpha 版 本 只 支持 静态 配置 卷 。 使 用 原始 块 设 备 时 ， 管 理 员 应 该 注意 考虑 这 


主意 : 
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Ho 
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a 5] 4S HB a 


如 果 您 正在 编写 在 多 种 群集 上 运行 并 需要 持久 存储 的 配置 模板 或 示例 ， 我 们 建议 您 
使 用 以 下 模式 : 


e 不 要 在 您 的 在 配置 组 合 中 包含 PersistentVolumeClaim WR (与 
Deployment、ConfigMap 等 一 起 ) 。 
不 要 在 配置 中 包含 PersistentVolume 对 象 ， 因 为 用 户 实例 化 配置 可 能 没有 
创建 PersistentVolume 的 权限 。 
给 用 户 在 实例 化 模板 时 提供 存储 类 名 称 的 选项 。 
o 如 果 用 户 提供 存储 类 名 称 ， 则 将 该 值 放 入 
persistentVolumeClaim.storageClassName 字段 中 。 如 果 集 群 具有 
由 管理 员 启 用 的 StorageClass， 这 将 导致 PVC 匹配 正确 的 存储 类 别 。 
o 如 果 用 户 未 提供 存储 类 名 称 ， 则 将 
persistentVolumeClaim.storageClassName 字段 保留 为 nil 。 

m 这 将 导致 使 用 集群 中 默认 的 StorageClass 为 用 户 自动 配置 PV。 许 多 
集群 环境 都 有 默认 的 StorageClass， 或 者 管理 员 可 以 创建 自己 的 默认 
StorageClass ° 

e 在 您 的 工具 中 ， 请 注意 一 段 时 间 之 后 仍 未 绑 定 的 PVC， 并 向 用 户 展 示 它 们 ， 
为 这 表示 集群 可 能 没有 动态 存储 支持 (在 这 种 情况 下 用 户 应 创建 匹配 的 
PV) ， 或 集群 没有 存储 系统 (在 这 种 情况 下 用 户 不 能 部 署 需 要 PVC 的 配 
E) 。 
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StorageClass 


本 文 介绍 了 Kubernetes T StorageClass 的 概念 。 在 阅读 本 文 之 前 建议 先 熟悉 
卷 和 Persistent Volume (持久 卷 ) 。 


4r 28 


StorageClass 为 管理 员 提 供 了 描述 存储 "class (类 ) "的 方法 。 不 同 的 class 
可 能 会 映射 到 不 同 的 服务 质量 等 级 或 备份 策略 ， 或 由 群集 管理 员 确定 的 任意 策略 。 
Kubernetes 本 身 不 清楚 各 种 class 代表 的 什么 。 这 个 概念 在 其 他 存储 系统 中 有 时 被 
称 为 "配置 文件 "。 


StorageClass 资源 


StorageClass 中 包含 provisioner ^ parameters 和 reclaimPolicy 字 
段 ， 当 class 需要 动态 分 配 PersistentVolume 时 会 使 用 到 。 


StorageClass 对 象 的 名 称 很 重要 ， 用 户 使 用 该 类 来 请 求 一 个 特定 的 方法 。 当 创 
建 StorageClass 对 象 时 ， 管 理 员 设 置 名 称 和 其 他 参数 ， 一 旦 创建 了 对 象 就 不 能 
再 对 其 更 新 。 


管理 员 可 以 为 没有 申请 绑 定 到 特定 class 的 PVC 指定 一 个 默认 的 StorageClass 


: 更 多 详情 请 参阅 PersistentVolumeClaim 章节 。 


kind: StorageClass 
apiVersion: storage.k8s.io/vi 
metadata: 

name: standard 
provisioner: kubernetes.io/aws-ebs 
parameters: 

type: gp2 
reclaimPolicy: Retain 
mountOptions: 

- debug 


v 


Provisioner (存储 分 配器 ) 


Storage class 有 一 个 分 配器 ， 用 来 决定 使 用 哪个 卷 插件 分 配 PV。 该 字段 必须 指 


定 。 


Volume Plugin 
AWSElasticBlockStore 
AzureFile 
AzureDisk 
CephFS 
Cinder 
FC 
FlexVolume 
Flocker 
GCEPersistentDisk 
Glusterfs 
iSCSI 
PhotonPersistentDisk 
Quobyte 
NFS 
RBD 
VsphereVolume 
PortworxVolume 
ScalelO 
StorageOS 


V 


Internal Provisioner 


Config Example 
AWS 
Azure File 
Azure Disk 
OpenStack Cinder 


GCE 
Glusterfs 


Quobyte 

Ceph RBD 
vSphere 
Portworx Volume 
ScalelO 
StorageOS 


您 不 限于 指定 此 处 列 出 的 "内 置 "分 配器 (其 名 称 前 组 为 kubernetes.io 并 打包 在 


Kubernetes 中 ) 
Kubernetes 定义 的 规范 


。 您 还 可 以 运行 和 指定 外 部 分 配器 ， 这 些 独立 的 程序 遵循 由 
。 外 部 供应 商 的 作者 完全 可 以 自由 决定 他 们 的 代码 保存 于 


何 处 、 打 包 方式 、 运 行 方式 、 使 用 的 插件 (包括 Flex) 等 。 代码 仓库 kubernetes- 
incubator/external-storage 包含 一 个 用 于 为 外 部 分 配器 编写 功能 实现 的 类 库 ， 以 及 


各 种 社区 维护 的 外 部 分 配器 。 


例如 ，NFS 没有 内 部 分 配器 ， 但 可 以 使 用 外 部 分 配器 。 一 些 外 部 分 配器 在 代码 仓库 
kubernetes-incubator/external-storage 中 。 也 有 第 三 方 存储 供应 商 提供 自己 的 外 


部 分 配器 。 


关于 内 置 的 StorageClass 的 配置 请 参考 Storage Classes。 


回收 策略 


由 storage class 动态 创建 的 Persistent Volume 会 在 的 reclaimPolicy 字段 中 
Ex 回收 策略 ， 可 以 是 Delete 或 者 Retain 。 如 果 StorageClass 对 象 被 创 
建 时 没有 指定 reclaimPolicy ， 它 将 默认 为 Delete 。 


通过 storage class 手动 创建 并 管理 的 Persistent Volume 会 使 用 它们 被 创建 时 指定 
的 回收 政策 。 


挂 载 选项 


由 storage class 动态 创建 的 Persistent Volume 将 使 用 class 中 mountOptions 
字段 指定 的 挂 载 选 项 。 


如 果 卷 插件 不 支持 挂 载 选项 ， 却 指定 了 该 选项 ， 则 分 配 操 作 失 败 。 安装 选项 在 
class 和 PV 上 都 不 会 做 验证 ， 所 以 如 果 挂 载 选项 无 效 ， 那 么 这 个 PV 就 会 失败 。 


参数 


Storage class 具有 描述 属于 storage class 卷 的 参数 。 取 决 于 FRE ， 可 以 接受 
不 同 的 参数 。 例如， 参数 type WH io1 和 参数 iopsPerGB 特定 于 EBS 
PV。 当 参数 被 省 略 时 ， 会 使 用 默认 值 。 


e https://kubernetes.io/docs/concepts/storage/storage-classes/ 
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本 地 持久 化 存储 


本 地 持久 化 卷 允 许 用 户 通过 标准 PVC 接口 以 简单 便携 的 方式 访问 本 地 存储 。PV 中 
包含 系统 用 于 将 Pod 安排 到 正确 节点 的 节点 亲 和 性 信息 。 


一 旦 配置 了 本 地 卷 ， 外 部 静态 配置 器 (provisioner) 可 用 于 帮助 简化 本 地 存储 管 
理 。 请 注意 ， 本 地 存储 配置 器 与 大 多 数 配 置 器 不 同 ， 并 且 尚 不 支持 动态 配置 。 相 
反 ， 它 要 求 管理 员 预 先 配 置 每 个 节点 上 的 本 地 卷 ， 并 且 这 些 卷 应 该 是 : 


1. Filesystem volumeMode (RU) PV 一 一 将 它们 挂 载 到 发 现 目 录 下 。 
2. Block volumeMode PV 一 一 在 发 现 目 录 下 为 节点 上 的 块 设 备 创 建 一 个 符号 链 
接 。 


配置 器 将 通过 为 每 个 卷 创 建 和 清除 PersistentVolumes 来 管理 发 现 目录 下 的 卷 。 
置 要 求 
e 本 地 卷 插 件 希 望 路 径 稳 定 ， 包 括 在 重新 启动 时 和 添加 或 删除 磁盘 时 。 


e 静 态 配置 器 仅 发 现 挂 载 点 (对 于 文件 系统 模式 卷 ) 或 符号 链接 (对 于 块 模式 
A) 。 对 于 基于 目录 的 本 地 卷 必 须 绑 定 到 发 现 目录 中 。 


WAR FRE 
推荐 配置 器 版 本 与 Kubernetes 版 本 
Provisioner version K8s version Reason 
2.1.0 1.10 Beta API default, block 
2.0.0 1.8, 1.9 Mount propagation 
1.0.1 1.7 
K8s fe KA 


另 请 参阅 已 知 问题 和 CHANGELOG e 


1.10 : Beta 


e 添加 了 新 的 PV.NodeAffinity 字段 。 
e 重要 : Alpha PV NodeAffinity annotation 已 齐 用 。 用 户 必 须 手 动 更 新 其 PV 以 
使 用 新 的 NodeAffinity 字 段 或 运行 一 次 性 更 新 作业 。 
e Alpha : 添加 了 对 raw block 的 支持 。 
1.9 : Alpha 


e idi ees volumeBindingMode 参数 将 延迟 PVC 绑 定 ， 直 到 pod 被 
调度 


1.7 : Alpha 


e 新 的 local PersistentVolume 源 ， 允 许 指 定 具有 node affinity 的 目录 或 挂 载 


e 使 用 绑 定 到 该 PV 的 PVC 的 Pod 将 始终 调度 到 该 节点 。 


未 来 的 功能 


e 本 地 块 设备 作为 卷 源 ， 具 有 分 区 和 fs 格式 化 
e 共享 本 地 持久 化 存储 的 动态 资源 调配 

e 当地 PV 健康 监测 、 污 点 和 容忍 

e AR PV (使 用 专用 本 地 磁盘 作为 临时 存储 ) 


用 户 指南 


这 些 说 明 反 映 了 最 新 版 本 的 代码 库 。 有 关 昌 版 本 的 说 明 ， 请 参阅 版 本 兼容 性 下 的 版 
本 链接 。 


步骤 1 : 使 用 本 地 磁盘 尼 动 集群 


È M alpha feature gate 


1.10+ 


如 果 需 要 原始 的 本 地 块 功能 ， 


export KUBE_FEATURE_GATES ="BlockVolume = true" 


注意 : 1.10 之 前 的 Kubernetes 版 本 需要 几 个 附加 feature gate， 因 为 持久 的 本 地 
卷 和 其 他 功能 处 于 alpha 版 本 。 


选项 1 : 裸 金 属 环境 


1. 根据 应 用 程序 的 要 求 对 每 个 节点 上 的 磁盘 进行 分 区 和 格式 化 。 
2. 根据 StorageClass 将 所 有 文件 系统 挂 载 到 同一 个 目录 下 。 目 录 在 configmap 
中 指定 ， 见 下 文 。 
3. 使 用 KUBE_FEATURE_GATES 配置 Kubernetes API server、controller 
manager ` scheduler 和 所 有 kubelet， 如 上 所 述 。 
4. 如 果 不 使 用 默认 Kubernetes 调度 程序 策略 ， 则 必须 启用 以 下 谓词 : 
o 1.9 之 前 : NoVolumeBindConflict 


o 1.9+ : VolumeBindingChecker 


选项 2 : 本 地 测试 集群 
1. 创建 /mnt/disks 目录 并 将 多 个 卷 挂 载 到 其 子 目 录 。 下 面 的 示例 使 用 三 个 
ram BARRA KAAS: 


mkdir/mnt/disks 

vol for voli vol2 vol3;do 
mkdir/mnt/disks/$vol 

mount -t tmpfs $vol/mnt/disks/$vol 
DONE 


2. 运行 本 地 集群 。 


$ALLOW_PRIVILEGED = true LOG_LEVEL = 5 FEATURE_GATES = $KUBE 
_FEATURE_GATES hack/local-up-cluster.sh 


步骤 2 : 创建 StorageClass (1.9+) 


要 延迟 卷 绑 定 ， 直 到 pod 被 调度 ， 并 在 单个 pod 中 处 理 多 个 本 地 PV， 必 须 使 用 设 
aA WaitForFirstConsumer 的 volumeBindingMode 创建 StorageClass。 


$kubectl create -f provisioner/deployment/kubernetes/example/def 
ault example storageclass.yaml 


步骤 3 : 创建 本 地 持久 卷 


选项 1 : 使 用 本 地 卷 静态 配置 器 


1. 生成 Provisioner 的 ServiceAccount ` Role ` DaemonSet 和 ConfigMap 7X, 
范 ， 并 对 其 进行 自 定义 。 
这 一 步 使 用 helm 模板 来 生成 规格 。 有 关 安 装 说 明 ， 请 参阅 helm readme » € 
使 用 默认 值 生成 配置 器 的 规格 ， 请 运行 : 


helm template ./helm/provisioner > ./provisioner/deployment/ 
kubernetes/provisioner generated.yaml 


您 也 可 以 提供 一 个 自 定 义 值 文件 : 


helm template ./helm/provisioner --values custom-values.yaml 
> ./provisioner/deployment/kubernetes/provisioner_generated. 
yaml 


| 
2. 部 署 配置 程序 


如 果 用 户 对 Provisioner 的 yaml 文件 的 内 容 感到 满意 ， 可 以 用 kubectl 创建 
Provisioner 的 DaemonSet 和 ConfigMap ° 


$kubectl create -f ./provisioner/deployment/kubernetes/provi 
sioner generated.yaml 


3. 检查 发 现 的 本 地 卷 
一 旦 启动 ， 外 部 静态 配置 器 将 发 现 并 创建 本 地 PV。 


例如 ， 如 果 目 录 /mnt/disks/ 包含 一 个 目录 /mnt/disks/vol1 ， 则 静态 
配置 器 会 创建 以 下 本 地 卷 PV: 


$ kubectl get pv 


NAME CAPACITY ACCESSMODES RECLAIMPOLICY 
STATUS CLAIM STORAGECLASS REASON AGE 

local-pv-ce05be60 1024220Ki RWO Delete 
Available local-storage 26s 


$ kubectl describe pv local-pv-ce05be60 


Name: local-pv-ce05be60 

Labels: <none> 

Annotations: pv.kubernetes.io/provisioned-by=local-volume 
-provisioner -minikube-18f57fb2-a186-11e7 -b543-080027d51893 
StorageClass: local-fast 

Status: Available 

Claim: 

Reclaim Policy: Delete 

Access Modes: RWO 

Capacity: 1024220Ki 

NodeAffinity: 


Required Terms: 
Term 0: kubernetes.io/hostname in [my-node] 


Message: 
Source: 
Type: LocalVolume (a persistent volume backed by loca 
l storage on a node) 
Path: /mnt/disks/vol1 
Events: <none> 


上 面 描述 的 PV 可 以 通过 引用 local-fast storageClassName 声明 和 绑 定 
到 PVC ° 


选项 2 : 手动 创建 本 地 持久 化 卷 


有 关 示 例 PersistentVolume 规范 ， 请 参阅 Kubernetes 文 档 。 


步 又 4 : 创建 本 地 持久 卷 声明 


kind: PersistentVolumeClaim 
apiVersion: vi 
metadata: 

name: example-local-claim 
spec: 

accessModes: 

- ReadwriteOnce 

resources: 

requests: 
storage: 5Gi 
storageClassName: local-storage 


请 替换 以 下 元 素 以 反映 您 的 配置 


e 卷 所 需 的 存储 容量 “5Gi” 
e “local-storage” ;与 本 地 PV 关联 的 存储 类 名 称 应 该 用 于 满足 此 PVC 


对 于 试图 声明 “Block” PV 49 "Block" volumeMode PVC， 可 以 使 用 以 下 示例 : 


kind: PersistentVolumeClaim 
apiVersion: v1 
metadata: 
name: example-local-claim 
spec: 
accessModes: 
- ReadWriteOnce 
resources: 
requests: 
storage: 5Gi 
volumeMode: Block 
storageClassName: local-storage 


请 注意 ， 此 处 唯一 需要 注意 的 字段 是 volumeMode， 它 已 被 设置 为 “Block”。 


最 住 实践 


e 对 于 |O 〇 隔离， 建议 每 个 卷 使 用 整个 磁盘 

e 对 于 容量 隔离 ， 建 议 使 用 单个 分 区 

e 避免 重新 创建 具有 相同 节点 名 称 的 节点 ， 而 仍然 存在 指定 了 该 节点 亲 和 性 的 旧 
PV。 否 则 ， 系 统 可 能 认为 新 节点 包含 昌 的 PV。 

e 对 于 带 有 文件 系统 的 卷 ， 建 议 在 fstab 条 目 和 该 挂 载 点 的 目录 名 称 中 使 用 它们 
的 UUID (例如 ls -l/dev/disk/by-uuid 的 输出 ) 。 这 种 做 法 可 确保 即使 
设备 路 径 发 生变 化 (例如 ， 如 果 /dev/sdal 在 添加 新 磁盘 时 变 为 


/dev/sdb1 ) ， 也 不 会 错误 地 挂 在 本 地 卷 。 此 外 ， 这 种 做 法 将 确保 如 果 创 建 
具有 相同 名 称 的 另 一 个 节点 ， 则 该 节点 上 的 任何 卷 都 是 唯一 的 ， 而 不 会 误 认 为 
是 具有 相同 名 称 的 另 一 个 节点 上 的 卷 。 

对 于 没有 文件 系统 的 raw block 卷 ， 使 用 唯一 的 ID 作为 符号 链接 名 称 。 根 据 您 
的 环境 ， /dev/disk/by-id/ 中 的 卷 ID 可 能 包含 唯一 的 硬件 序列 号 。 否 则 ， 
应 该 生成 一 个 唯一 的 ID。 符 号 链接 名 称 的 唯一 性 将 确保 如 果 创 建 具 有 相同 名 称 

的 另 一 个 节点 ， 则 该 节点 上 的 任何 卷 都 是 唯一 的 ， 而 不 会 误 认 为 是 具有 相同 名 

称 的 另 一 个 节点 上 的 卷 。 


删除 /清理 底层 卷 


当 您 想 要 停 用 本 地 卷 时 ， 以 下 是 可 能 的 工作 流程 。 


O A O N > 


- 


.停止 使 用 卷 的 pod 

.从 节点 中 删除 本 地 卷 〈 即 务 载 、 技 出 磁盘 等 ) 

. 删除 PVC 

.供应 商 将 尝试 清理 卷 ， 但 由 于 卷 不 再 存在 而 会 失败 
.手动 删除 PV 对 象 


考 


e Local Persistent Storage User Guide 
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扩展 


Kubernetes 是 一 个 高 度 开 放 可 扩展 的 架构 ， 可 以 通过 自 定 义 资 源 类 型 CRD 来 定义 自 
己 的 类 型 ， 还 可 以 自己 来 扩展 API 服 务 ， 用 户 的 使 用 方式 跟 Kubernetes 的 原生 对 象 
Kitt e 
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使 用 自 定 义 资 源 扩 展 API 


主意 : TPR 已 经 停止 维护 ，kubernetes 1.7 及 以 上 版 本 请 使 用 CRD。 


自 定 义 资 源 是 对 Kubernetes API 的 扩展 ，kubernetes 中 的 每 个 资源 都 是 一 个 API 对 
象 的 集合 ， 例 如 我 们 在 YAML 文 件 里 定义 的 那些 spec 都 是 对 kubernetes 中 的 资源 对 
象 的 定义 ， 所 有 的 自 定义 资源 可 以 跟 kubernetes 中 内 建 的 资源 一 样 使 用 kubectl 操 
作 。 


自 定义 资源 


Kubernetes1.6 版 本 中 包含 一 个 内 建 的 资源 叫做 TPR (ThirdPartyResource) ， 可 以 
用 它 来 创建 自 定义 资源 ， 但 该 资源 在 kubernetes1.7 中 版 本 已 被 
CRD (CustomResourceDefinition) 取代 。 


扩展 API 


自 定 义 资 源 实 际 上 是 为 了 扩展 Kubernetes 的 API， 向 kubenetes API 中 增加 新 类 型 ， 
可 以 使 用 以 下 三 种 方式 : 


e 修改 Kubenetes 的 源码 ， 显 然 难度 比较 高 ， 也 不 太 合 适 
e 创建 自 定 义 API server 并 聚合 到 API| 中 
e 1.7 以 下 版 本 编写 TPR，kubernetes1.7 及 以 上 版 本 用 CRD 


编写 自 定义 资源 是 扩展 kubernetes API 的 最 简单 的 方式 ， 是 否 编 写 自 定义 资源 来 扩 
展 API 请 参考 Should | add a custom resource to my Kubernetes Cluster?， 行 动 前 
请 先 考虑 以 下 几 点 : 


e 你 的 API 是 否 属于 声明 式 的 
否 想 使 用 kubectl 命 令 来 管理 
否 要 作为 Kubenretes 中 的 对 象 类 型 来 管理 ， 同 时 显示 在 kuberetes dashboard 


is m D 


否 可 以 遵守 kubernetes 的 API 规 则 限制 ， 例 如 URL 和 API group ` namespace 
限制 
e 是 否 可 以 接受 该 API 只 能 作用 于 集群 或 者 namespace 范 


e 722 E Jl kubernetes API 的 公共 功能 ， 比 如 CRUD、watch、 内 置 的 认证 和 授权 


如 果 这 些 都 不 是 你 想 要 的 ， 那 么 你 可 以 开发 一 个 独立 的 API 。 


TPR 


注意 : TPR 已 经 停止 维护 ，kubernetes 1.7 及 以 上 版 本 请 使 用 CRD 。 


假如 我 们 要 创建 一 个 名 为 cron-tab.stable.example.com 的 TPR，yaml 文 件 定 
义 如 下 : 


apiVersion: extensions/vibetai 
kind: ThirdPartyResource 
metadata: 
name: cron-tab.stable.example.com 
description: "A specification of a Pod to run on a cron style sc 
hedule" 
versions: 
- name: vi 


然后 使 用 kubectl create 命令 创建 该 资源 ， 这 样 就 可 以 创建 出 一 个 API 端 
点 /apis/stable.example.com/vi/namespaces/«namespace»/crontabs/... 


o 


下 面 是 在 Linkerd 中 的 一 个 实际 应 用 ，Linkerd 中 的 一 个 名 为 namerd 的 组 件 使 用 了 
TPR， 定 义 如 下 : 


kind: ThirdPartyResource 
apiVersion: extensions/vibeta1 
metadata: 
name: d-tab.l5d.io 
description: stores dtabs used by namerd 
versions: 
- name: vialphat 


CRD 


参考 下 面 的 CRD ° resourcedefinition.yaml : 


ey bs sy RJR 
Ae Jt] E] SS w/e 
IX / tj E] EXTIA 


apiVersion: apiextensions.k8s.io/vibeta1 
kind: CustomResourceDefinition 
metadata: 
B 名 称 必 须 符 合 下 面 的 格式 : <plural>.<group> 
name: crontabs.stable.example.com 
spec: 
# REST API 使 用 的 组 名 称 : /apis/<group>/<version> 
group: stable.example.com 
# REST API 使 用 的 版 本 号 : /apis/<group>/<version> 
version: v1 
4 Namespaceds3iCluster 
scope: Namespaced 
names: 
# URL 中 使 用 的 复数 名 称 ; /apis/<group>/<version>/<plural> 
plural: crontabs 
A CLI 中 使 用 的 单数 名 称 
singular: crontab 
# CamelCased 格 式 的 单数 类 型 。 在 清单 文件 中 使 用 
kind: CronTab 
# CLI 中 使 用 的 资源 简称 
shortNames: 
- ct 


创建 该 CRD : 


kubectl create -f resourcedefinition.yaml 


访问 RESTful API 端 点 如 http:/172.20.0.113:8080 将 看 到 如 下 API 端 点 已 创建 : 


/apis/stable.example.com/vi/namespaces/*/crontabs/... 


创建 自 定 义 对 象 


如 下 所 示 : 


apiVersion: "stable.example.com/vi" 
kind: CronTab 
metadata: 
name: my-new-cron-object 
spec: 
eronspec: "* * * * 7/5" 
image: my-awesome-cron-image 


引用 该 自 定 义 资 源 的 API 创 建 对 象 。 
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En: 


终止 器 


可 以 为 自 定义 对 象 添加 一 个 终止 器 ， 如 下 所 示 : 


apiVersion: "stable.example.com/vi" 
kind: CronTab 
metadata: 

finalizers: 

- finalizer.stable.example.com 


MIE A LLM SRI AFRITA o T AUR ZRIE S 89 — 4o Eo PES Rt 
是 为 metadata.deletionTimestamp 字段 设置 一 个 值 ， 而 不 是 删除 它 ， 这 将 触发 
监控 该 对 象 的 控制 器 执行 他 们 所 能 处 理 的 任意 终止 器 。 


详情 参考 : Extend the Kubernetes API with CustomResourceDefinitions 


使 用 kubernetes1.7 及 以 上 版 本 请 参考 Migrate a ThirdPartyResource to 
CustomResourceDefinition ° 


自 定 义 控 制 器 


单纯 设置 了 自 定义 资源 ， 并 没有 什么 用 ， 只 有 跟 自 定义 控制 器 结合 起 来 ， 才 能 讲 资 
源 对 象 中 的 声明 式 API 翻 译 成 用 户 所 期 望 的 状态 。 自 定义 控制 器 可 以 用 来 管理 任何 
资源 类 型 ， 但 是 一 般 是 跟 自 定义 资源 结合 使 用 。 


请 参考 使 用 Operator 模 式 ， 该 模式 可 以 让 开发 者 将 自己 的 领域 知识 转换 成 特定 的 
kubenretes API 扩 展 。 


API server > 


Aggregated (聚合 的 ) API server£4 T 34 /$ KMAPI server 这 个 巨石 

(monolithic) 应 用 给 拆 分 成 ， 为 了 方便 用 户 开发 自己 的 API server 和 集成 进来 ， 而 不 
用 直接 修改 kubernetes 官 方 仓库 的 代码 ， 这 样 一 来 也 能 将 API server RAS > Z7 48 70 
户 使 用 实验 特性 。 这 些 API server 可 以 跟 core API server 无 颖 衔接， 试用 kubectl 也 
可 以 管理 它们 。 


详情 参考 Aggregated API Server ° 


e Custom Resources 
e Extend the Kubernetes API with CustomResourceDefinitions 
e Introducing Operators: Putting Operational Knowledge into Software 
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Aggregated API Server 


Aggregated (#445) API server 是 为 了 将 原来 的 API server 这 个 巨石 

(monolithic) 应 用 给 拆 分 成 ， 为 了 方便 用 户 开发 自己 的 API server 集 成 进来 ， 而 不 
用 直接 修改 kubernetes 官 方 仓库 的 代码 ， 这 样 一 来 也 能 将 API serverii > 7 8 7 
户 使 用 实验 特性 。 这 些 API server 可 以 跟 core API server 无 缝 衔 接 ， 使 用 kubectl 也 
TEST ^ 


ARI 


我 们 需要 创建 一 个 新 的 组 件 ， 名 为 kube-aggregator ， 它 需要 负责 以 下 几 件 事 : 


e 提供 用 于 注册 APl server 的 API 
e. 汇总 所 有 的 API server 信 息 
e 代理 所 有 的 客户 端 到 API server 的 请 求 


注意 : 这 里 说 的 API server 是 一 组 “API Server”， 而 不 是 说 我 们 安装 集群 时 候 的 那个 
API server > 而且 这 组 AP| server 是 可 以 横向 扩展 的 。 


KT RE WAPI server 的 更 多 信息 请 参考 : Aggregated API Server 


安装 配置 聚合 的 API server 
有 两 种 方式 来 启用 kube-aggregator 


e 使 用 test mode/single-user mode， 作 为 一 个 独立 的 进程 来 运行 
e 使 用 gateway mode’ kube-apiserver #2] kbe-aggregator 组 件 
中 ， 它 将 作为 一 个 集群 的 gateway， 用 来 聚合 所 有 apiserver。 


kube-aggregator 二 进 制 文件 已 经 包含 在 kubernetes release 里 面 了 。 


Aggregated API Servers - kuberentes design-proposals 
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APIService 


APIService 是 用 来 表示 一 个 特定 的 Groupversion 的 中 的 server， 它 的 结构 定义 位 
于 代码 staging/src/k8s.io/kube- 
aggregator/pkg/apis/apiregistration/types.go 中 。 


下 面 是 一 个 APIService 的 示例 配置 : 


apiVersion: apiregistration.k8s.io/vibeta1 
kind: APIService 
metadata: 


name: vialphai.custom-metrics.metrics.k8s.io 
spec: 
insecureSkipTLSVerify: true 
group: custom-metrics.metrics.k8s.io 
groupPriorityMinimum: 1000 
versionPriority: 5 
service: 
name: api 
namespace: custom-metrics 
version: vialphai 


APIServicei£ f£ 


使 用 apiregistration.k8s.io/vibetai 版 本 的 APlService， 在 metadata.name 
中 定义 该 API 的 名 字 。 


使 用 上 面 的 yaml 的 创建 v1alpha1l.custom-metrics.metrics.k8s.io 
APlService。 


e insecureSkipTLSVerify : 当 与 该 服务 通信 时 ， 禁 用 TLS 证 书 认 证 。 强 加 建 
议 不 要 设置 这 个 参数 ， 默 认为 false。 应 该 使 用 CABundle 代 替 。 

e service : 与 该 APIService 通 信 时 引用 的 service， 其 中 要 注 明 service 的 名 字 
和 所 属 的 namespace， 如 果 为 空 的 话 ， 则 所 有 的 服务 都 会 该 API groupversion 
将 在 本 地 443 端 口 处 理 所 有 通信 。 

e groupPriorityMinimum : 该 组 API 的 处 理 优先 级 ， 主 要 排序 是 基 
于 groupPriorityMinimum ， 该 数字 越 大 表明 优先 级 越 高 ， 客 户 端 就 会 与 其 
通信 处 理 请 求 。 次 要 排序 是 基于 字母 表 顺 序 ， 例 如 v1.bar 比 v1.foo 的 优先 级 更 


o 


Os) 


e versionPriority : VersionPriority 控 制 其 组 内 的 API 版 本 的 顺序 。 必 须 大 于 
零 。 主 要 排序 基于 VersionPriority， 从 最 高 到 最 低 (20 大 于 10) 排序 。 次 要 排 
序 是 基于 对 象 名 称 的 字母 比较 。 (v1.foo 在 v1.bar 之 前 ) 由 于 它们 都 是 在 一 个 
组 内 ， 因 此 数字 可 能 很 小 ， 一 般 都 小 于 10。 


查看 我 们 使 用 上 面 的 yaml 文 件 创建 的 APlService。 


kubectl get apiservice vialphai.custom-metrics.metrics.k8s.io -o 
yaml 


apiVersion: apiregistration.k8s.io/vibeta1 
kind: APIService 
metadata: 
creationTimestamp: 2017-12-14T08:27:35Z 
name: vialphai.custom-metrics.metrics.k8s.io 
resourceVersion: "35194598" 
selfLink: /apis/apiregistration.k8s.io/vibetal/apiservices/via 
lphai.custom-metrics.metrics.k8s.io 
uid: a31a3412-e0a8-11e7-9fa4-f4e9d49f8edO 
spec: 
caBundle: null 
group: custom-metrics.metrics.k8s.io 
groupPriorityMinimum: 1000 
insecureSkipTLSVerify: true 
service: 
name: api 
namespace: custom-metrics 
version: vialphat 
versionPriority: 5 
Status: 
conditions: 
- lastTransitionTime: 2017-12-14T08:27:38Z 
message: all checks passed 
reason: Passed 
status: "True" 
type: Available 


查看 集群 支持 的 APlSerivce 


作为 Kubernetes 中 的 一 种 资源 对 象 ， 可 以 使 用 kubectl get apiservice 来 查 
看 o 


例如 查看 集群 中 所 有 的 APIService : 


$ kubectl get apiservice 


NAME AGE 
vi. 2d 
vi.authentication.k8s.io 2d 
vi.authorization.k8s.io 2d 
vi.autoscaling 2d 
vi.batch 2d 
vi.monitoring.coreos.com 1d 
vi.networking.k8s.io 2d 
vi.rbac.authorization.k8s.io 2d 
vi.storage.k8s.io 2d 
vialphai.custom-metrics.metrics.k8s.io 2h 
vibetai.apiextensions.k8s.io 2d 
vibetai1.apps 2d 
vibetai1.authentication.k8s.io 2d 
vibetai.authorization.k8s.io 2d 
vibetai.batch 2d 
vibeta1.certificates.k8s.io 2d 
vibetal.extensions 2d 
vibeta1.policy 2d 
vibeta1l.rbac.authorization.k8s.io 2d 
vibeta1.storage.k8s.io 2d 
vibeta2.apps 2d 
v2beta1.autoscaling 2d 


另外 查看 当前 kubernetes 集 群 支持 的 API 版 本 还 可 以 使 用 kubectl api- 


version 


$ kubectl api-versions 
apiextensions.k8s.io/vi1betai 
apiregistration.k8s.io/vibetai 
apps/vibeta1i 

apps/vibeta2 

authentication. k8s.io/v1i 
authentication. k8s.io/vibeta1 
authorization.k8s.io/v1 
authorization.k8s.io/vibetat 
autoscaling/v1 
autoscaling/v2beta1 

batch/v1 

batch/vibeta1 

certificates. k8s.io/vibeta1 
custom-metrics.metrics.k8s.i0/vialpha1 
extensions/vibetai 
monitoring.coreos.com/v1 
networking. k8s.i0/v1 
policy/vibetai 
rbac.authorization.k8s.i0/v1 
rbac.authorization.k8s.io/vibetai 
storage.k8s.i0/v1 
storage.k8s.io/vibetai 

vi 


API Conventions 
Kuberentes1.8 reference doc 
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务 目录 (Service Catalog) 


服务 目录 (Service Catalog) ;EKubernetes 55 4^ RAPI > E1% 34 41 4€ Kubernetes % 
群 中 的 应 用 程序 可 以 轻松 使 用 外 部 托管 软件 产品 ， 例 如 由 云 提 供 商 提供 的 数据 存储 
服务 o 


它 提供 列表 清单 、 提 供 (provision) 和 绑 定 (binding) 来 自 服务 代理 (Service 
Brokers) 的 外 部 托管 服务 ， 而 不 需要 关心 如 何 创 建 或 管理 这 些 服务 的 详细 情况 。 


由 Open Service Broker API 规 范 定义 的 Service broker 是 由 第 三 方 提 供 和 维护 的 一 
组 托管 服务 的 端点 (endpoint)， 该 第 三 方 可 以 是 AWS，GCP 或 Azure 等 云 提供 商 。 


托管 服务 可 以 是 Microsoft Azure Cloud Queue，Amazon Simple Queue Service 和 
Google Cloud Pub/Sub 等 ， 它 们 可 以 是 应 用 可 以 使 用 的 提供 的 各 种 软件 。 


通过 Service Catalog， 集 群 运营 者 可 以 浏览 由 Service Broker 提 供 的 托管 服务 列 
表 ， 提 供 的 托管 服务 实例 ， 并 与 其 绑 定 ， 使 其 可 被 Kubernetes 集 群 中 的 应 用 程序 所 
使 用 。 


Dy x MP 


应 用 程序 开发 人 员 编 写 基于 Kubernetes 和 集群 的 应 用 程序 ， 他 们 希望 使 用 消息 队列 作 
为 其 应 用 程序 eid e。 但是， 他 们 不 想 自 己 配置 和 管理 这 个 服务 服务 。 恰 好 ， 有 
一 家 云 提供 商 通过 其 服务 代理 (Service Broker) 提 供 消息 队列 服务 。 


集群 运营 商 可 以 设置 Service Catalog 并 使 用 它 与 云 提 供 商 的 Service Broker 进 行 通 
信 ， 以 调配 消息 排队 服务 的 实例 并 使 其 可 用 于 Kubernetes 集 群 内 的 应 用 程序 。 因 
此 ， 应 用 程序 开发 人 员 不 需要 关心 消息 队列 的 实现 细节 或 管理 ， 可 以 简单 地 像 服 务 
一 样 使 用 它 。 


架构 
Service Catalog 使 用 Open Service Broker API 与 Service Broker 4 ip ， 充 当 
Kubernetes API 服 务 器 的 中 介 ， 发 起 供应 并 返回 应 用 程序 使 用 托管 服 需 的 赁 


据 。 


Service Catalog 


Service Catalog 通 过 扩展 API 服 务 器 和 控制 器 实现 ， 使 用 etcd 进 行 存 储 。 它 还 使 用 
Kubernetes 1.7+ 中 提供 的 聚合 层 来 呈现 其 AP|。 
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Service Broker Z 


Kubernetes 


B - Service Catalog Architecture 
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Service Catalog Z X servicecatalog.k8s.ioAPI # 42 4% YA VAT Kubernetes 3t 7$. : 


e ClusterServiceBroker : 作为 service broker 的 群集 内 代理 ， 封 装 其 服务 器 连接 
详细 信息 。 这 些 由 集群 运营 者 创建 和 管理 ， 硕 望 使 用 broker 服 务 在 其 集群 中 提 
供 新 类 型 的 托管 服务 。 


e ClusterServiceClass : 由 特定 service broker 提 供 的 托管 服务 。 将 新 
ClusterServiceBroker 资 源 添 加 到 群集 时 ，Service catalog controller 将 连接 到 
service broker 以 获取 可 用 托管 服务 的 列表 清单 。 然 后 它 会 创建 新 的 
ClusterServiceClass 资 源 ， 与 每 个 托管 服务 相对 应 。 


e ClusterServicePlan : 托管 服务 的 特定 产品 。 例 如 ， 托 管 服 务 可 能 有 不 同 的 可 
用 套餐 ， 例 如 免费 套餐 或 付费 套餐 ， 或 者 可 能 有 不 同 的 配置 选项 ， 例 如 使 用 
SSD 存 储 或 拥有 更 多 资源 。 同 向 群集 添加 ClusterServiceClass 一 样 ， 当 添加 一 
个 新 的 ClusterServiceBroker 时 ，Service Catalog 会 创建 一 个 新 的 
ClusterServicePlan 资 源 ， 与 每 个 托管 服务 可 用 的 每 个 服务 套餐 对 应 。 


e Servicelnstance : 一 个 提供 好 的 ClusterServiceClass 实 例 。 这 些 是 由 集群 运营 
者 创建 的 托管 服务 的 特定 实例 ， 供 一 个 或 多 个 集群 内 应 用 程序 使 用 。 当 创建 一 
个 新 的 Servicelnstance 资 源 时 ，Service Catalog controller 连 接 到 相应 的 服务 
代理 并 指示 它 提 供 服务 实例 。 


e ServiceBinding : 访问 Servicelnstance 的 凭据 。 由 想 让 他 们 的 应 用 利用 
Servicelnstance 的 集群 集运 营 者 创建 。 创 建 之 后 ，Service Catalog controller 
将 创建 一 个 与 此 服务 实例 对 应 的 Kubernetes 的 Secret， 包 含 此 服务 实例 的 连接 
详细 信息 和 和 赁 证 ， 可 以 挂 载 到 Pod 中 。 


鉴 权 认证 
Service Catalog 支持 这 些 认 证 方法 : 


e Basic (username/password) 
e OAuth 2.0 Bearer Token 


用 法 


群集 运营 者 可 以 使 用 Service Catalog API 资 源 来 提供 托管 服务 ， 并 使 其 在 
Kubernetes 群 集中 可 用 。 涉 及 的 步骤 是 : 


. 列 出 Service Broker 提 供 的 托管 服务 清单 和 服务 套餐 。 
. 提供 托管 服务 的 新 实例 。 

. 绑 定 到 托管 服务 ， 该 服务 返回 连接 凭证 。 
. 将 连接 凭证 映射 到 应 用 程序 中 。 


BOND 一 


列 出 托管 服务 和 服务 套餐 


首先 ， 群 集运 营 者 必须 在 servicecatalog.k8s.io 群 组 内 创建 ClusterServiceBroker 资 
源 。 此 资源 包含 访问 服务 代理 端点 所 需 的 URL 和 连接 详细 信息 。 


这 是 一 个 ClusterServiceBroker 资 源 的 例子 : 


apiVersion: servicecatalog.k8s.io/vibeta1 
kind: ClusterServiceBroker 
metadata: 

name: cloud-broker 
spec: 

# Points to the endpoint of a service broker. (This example is 
not a working URL.) 

url: https://servicebroker.somecloudprovider .com/vialpha1/pro 
jects/service-catalog/brokers/default 

HHH 

# Additional values can be added here, which may be used to co 
mmunicate 

# with the service broker, such as bearer token info or a caBu 
ndle for TLS. 

HHA 


以 下 是 说 明 从 一 个 service broker 列 出 托管 服务 和 套餐 所 涉及 步骤 的 顺序 图 : 


Cluster Operator Service Catalog Service Broker 
API Server 


ClusterServiceBroker 


一 
Resource 
| unl 1. 


List Services 


ClusterServiceClass 2 Plans 
get clusterserviceclasses Resource Services, Plans 


lam dul 


get clusterserviceplans ClusterServicePlan 


Resource 





图 片 List Services 


1. 4ClusterServiceBroker 3t 7$ 7&7» #] Service catalog 中 ， 它 会 触发 对 外 部 
Service Broker 的 调用 以 获取 可 用 服务 的 清单 。 

2. Service Broker 返 回 可 用 托管 服务 的 清单 和 服务 套餐 的 列表 ， 它 们 分 别 在 本 地 
缓存 为 ClusterServiceClass 资源 和 ClusterServicePlan 资源 。 

3. 然后 ， 集 群 运营 者 可 以 使 用 以 下 命令 获取 可 用 托管 服务 的 清单 : 


kubectl get clusterserviceclasses -o=custom-columns=SERVICE 
\ NAME: .metadata.name, EXTERNAL\ NAME: .spec.externalName 


它 应 该 输出 一 个 类 似 于 以 下 格式 的 服务 名 称 列 表 : 


SERVICE NAME EXTERNAL NAME 
4f6e6cf6-ffdd-425f-a2c7-3c9258ad2468 cloud-provider -servi 
ce 


他 们 还 可 以 使 用 以 下 命令 查看 可 用 的 服务 套餐 : 


kubectl get clusterserviceplans -o=custom-columns=PLAN\ NAM 
E:.metadata.name, EXTERNAL\ NAME:.spec.externalName 


它 应 该 输出 一 个 类 似 于 以 下 格式 的 套餐 名 称 列 表 : 


PLAN NAME EXTERNAL NAME 
86064792-7ea2-467b-af93-ac9694d96d52 service-plan-name 


提供 新 的 实例 


集群 运营 者 可 以 通过 创建 Servicelnstance 资 源 来 启动 新 实例 的 供应 。 


如 下 是 一 个 Servicelnstance 资 源 的 例子 : 


apiVersion: servicecatalog.k8s.io/vibeta1 

kind: ServiceInstance 

metadata: 
name: cloud-queue-instance 
namespace: cloud-apps 

spec: 
# References one of the previously returned services 
clusterServiceClassExternalName: cloud-provider-service 
clusterServicePlanExternalName: service-plan-name 
Se 
# Additional parameters can be added here, 
# which may be used by the service broker. 
HHHHH 


以 下 序列 图 说 明了 提供 一 个 新 的 托管 服务 的 实例 所 涉及 的 步 又 : 


Cluster Operator Service Catalog Service Broker 
API Server 


Servicelnstance 


> Resource 
m c 
Provision Instance 
~ 


1 
x 1 
p di Ns x 


Servicelnstance 
Resource 





— get serviceinstance —> 


READY 


图 片 - Provision a Service 


1. 4 ServiceInstance 资源 创建 后 ，Service Catalog & #2 2! 9} 48 service broker 
来 提供 服务 的 一 个 实例 。 

2. service broker 创 建 托管 服务 的 新 实例 并 返回 HTTP 响 应 。 

3. 然后 ， 群 集运 营 者 可 以 检查 实例 的 状态 ， 来 确认 它 是 否 准备 就 绪 。 


绑 定 到 托管 服务 


在 提供 新 实例 后 ， 群 集运 营 者 必须 绑 定 到 托管 服务 才能 获取 到 应 用 程序 使 用 服务 所 
需 的 连接 凭证 和 服务 帐户 详细 信息 。 这 是 通过 创建 ServiceBinding 资源 完成 
的 。 


以 下 是 一 个 ServiceBinding 资源 的 例子 : 


apiVersion: servicecatalog.k8s.io/vibeta1 
kind: ServiceBinding 
metadata: 

name: cloud-queue-binding 

namespace: cloud-apps 


spec: 
instanceRef : 
name: cloud-queue-instance 
Bee oS 


# Additional information can be added here, such as a secretNa 
me or 


# service account parameters, which may be used by the service 
broker. 
Bee 


以 下 序列 图 说 明了 绑 定 到 托管 服务 实例 所 涉及 的 步骤 : 


Cluster Operator Service Catalog Service Broker 
API Server 
n ServiceBinding 
Resource 
M 
Bind Instance 
~~ 
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Connection 
Information 
4— — 


ServiceBinding 


Resource 


图 片 Bind to a managed service 


1. 在 ServiceBinding 创 建 后 ，Service Catalog? ^l 3f service broker — 4-78 FF] 3 
求 ， 获 取 与 服务 实例 绑 定 所 需 的 信息 。 


2. service broker 为 相应 的 服务 帐户 启用 应 用 程序 权限 /角色 。 


3. service broker 返 回 连接 和 访问 托管 服务 实例 所 需 的 信息 。 根 据 不 同 的 提供 商 和 
不 同 的 服务 ， 返 回 的 信息 可 能 在 服务 提供 商 和 其 管理 服务 之 间 有 所 不 同 。 


Service Catalog 


映射 连接 凭证 


绑 定 后 ， 最 后 一 步 是 将 连接 赁 证 和 服务 特定 的 信息 映射 到 应 用 程序 中 。 这 些 信息 存 
储 在 secret 中 ， 应 用 程序 可 以 用 来 访问 并 与 托管 服务 连接 。 








API Server Service Catalog Bind Instance Service Broker 


Service Account 


servicecatalog.k8s.io: 


ServiceBinding 


Managed Service 


Application Instance 






Secret: 
Connection Credentials 
Service Account Details 


Kubernetes 


图 片 - Map connection credentials 


Podi E x fF 
执行 此 映射 的 一 种 方法 是 使 用 声明 式 Pod 配 置 文件 。 


以 下 示例 描述 了 如 何 将 服务 帐户 凭证 映射 到 应 用 程序 中 。 被 调用 的 sa-key 密 钥 存 储 
在 名 为 provider-cloud-key 的 卷 中 ， 并 且 应 用 程序 将 此 卷 挂 载 

3 /var/secrets/provider/key.json ° #368 = 

PROVIDER APPLICATION CREDENTIALS X M4 R XC fF 89 4& Ie AT a KKI o 


425 


spec: 
volumes: 
- name: provider -cloud-key 
secret: 
secretName: sa-key 
containers: 


volumeMounts: 

- name: provider -cloud-key 
mountPath: /var/secrets/provider 

env: 

- name: PROVIDER_APPLICATION_CREDENTIALS 
value: "/var/secrets/provider/key. json" 


以 下 示例 描述 如 何 将 secret 值 映射 到 应 用 程序 环境 变量 。 在 此 示例 中 ， 消 息 传递 队 
^| topic 名 称 从 名 为 provider-queue-credentials 的 secret 的 key topic 值 映射 
到 环境 变量 TOPIC 。 


env: 
- name: "TOPIC" 
valueFrom: 
secretKeyRef : 
name: provider -queue-credentials 
key: topic 


下 一 步 


e 40% 24 BHelm Charts ， 使 用 Helm 将 Service Catalog 安 装 到 Kubernetes 集 群 
中 。 或 者 ， 可 以 使 用 SC 工具 安装 服务 目录 。 

e 查看 sample service brokers. 

e 3% &kubernetes-incubator/service-catalog 项 目 。 


以 上 翻译 自 官方 文档 。 


Service Catalog 的 安装 (利用 Helm) 和 交互 


以 下 翻译 自 官方 项 目 文档 。 与 官方 网 站 文档 大 致 一 致 。 


Kubernetes 1.7 或 更 高 版 本 的 集群 运行 API Aggregator > ‘44 core API Server i 
面 的 专用 proxy 服 务 器 。 


服务 目录 (Service Catalog) 提 供 了 一 个 位 于 API aggregator 后 面 的 API Server， 因 此 
可 以 用 kubectl 像 平常 一 样 与 Service Catalog 进 行 交 互 。 


要 了 解 更 多 关于 API aggregation 的 信息 ， 请 参阅 Kubernetes 文 档 。 
本 文档 的 其 余部 分 详细 介绍 了 如 何 : 


e 在 群集 上 设置 Service Catalog 
e 与 Service Catalog API 进 行 交 互 


前 提 条 件 


Kubernetes 版 本 


Service Catalog 需 要 Kubernetes v1.7 或 更 高 版 本 。 您 还 需要 在 主机 上 安装 
Kubernetes configuration file 。 你 需要 这 个 文件 ， 以 便 可 以 使 用 kubectl 和 helm 与 
群集 通信 。 许 多 Kubernetes 安 装 工具 或 云 提供 商会 为 你 设置 此 配置 文件 。 有关 详 细 
信息 ， 请 与 您 的 工具 或 提供 商 联 系 。 

kubectl 版 本 


大 多 数 与 Service Catalog 系 统 的 交互 都 是 通过 kubectl 命令 行 界 面 实现 的 。 与 群 
集 版 本 一 样 ，Service Catalog 需 要 kubectl 版 本 1.7 或 更 高 版 本 。 


首先 ， 检 查 kubectl 版 本 : 


kubectl version 


确保 Kubernetes 版 本 和 kubectl 版 本 均 为 1.7 或 更 高 。 
如 果 需 要 升级 客户 端 ， 请 按照 安装 说 明 获取 新 的 kubectl 二 进 制 文件 。 


例如 ， 运 行 以 下 命令 以 在 Mac OS 上 获取 最 新 的 二 进 制 文件 : 


curl -LO https://storage.googleapis.com/kubernetes-release/relea 
se/$(curl -s https://storage.googleapis.com/kubernetes-release/r 
elease/stable.txt)/bin/darwin/amd64/kubectl 

chmod +x ./kubectl 


群集 内 DNS 


您 需要 启用 Kubernetes 集 群 内 的 DNS。 大 多 数 常用 的 安装 方法 会 为 您 自动 配置 群集 
内 DNS : 


e Minikube 
e hack/local-up-cluster.sh 


e 大 多 数 云 提供 商 


Helm 


使 用 Helm 安 装 Service Catalog ， 需 要 V2.7.0 或 更 高 版 本 。 请 参阅 以 下 步骤 进行 安 


J+ 


K 。 


如 果 还 没有 安装 Helm 

如 果 尚 未 安装 Helm， 请 下 载 helm CLI， 然 后 运行 helm init (这 会 将 Helm 的 服务 
器 端 组 件 Tiller 安 装 到 Kubernetes 群 集中 ) 。 

如 果 已 经 安装 了 Helm 


如 果 已 经 安装 了 Helm， 请 运行 helm version 并 确保 客户 端 和 服务 器 版 本 均 为 v2.7.0 


如 果 不 是 ， 请 安装 更 新 版 本 的 helm CLI 并 运行 helm init --upgrade 。 


有 关 安 装 的 更 多 详细 信息 ， 请 参阅 Helm 安 装 说 明 。 


Tiller 权限 


Tiller 是 Helm 的 服务 端 组 件 。 黑 认 情 况 下 > helm init 将 Tiller pod 安 装 到 kube-system 
名 称 空间 中 ， 并 将 Tiller 配 置 为 使 用 default 服 务 帐户 (service account) 。 


需要 对 Tiller 进 行 配置 cluster-admin 权限 ， 才 能 正确 安装 Service Catalog : 


kubectl create clusterrolebinding tiller-cluster-admin \ 
--clusterrole=cluster-admin \ 
--serviceaccount=kube-system:default 


Helm Repository^X £ 


Service Catalog 很 容易 通过 Helm chart X ° 
此 chart 位 于 chart repository 中 。 将 此 repository 添 加 到 本 地 计算 机 : 


helm repo add svc-cat https://svc-catalog-charts.storage.googlea 
pis.com 


然后 ， 确 保 repository 已 成 功 添加 : 


helm search service-catalog 


应 该 看 到 以 下 输出 : 
NAME VERSION DESCRIPTION 
Svc-cat/catalog X,y.Z service-catalog API server and con 


troller-manag... 


RBAC 


Kubernetes 群 集 必须 启用 RBAC 才能 使 用 Service Catalog ° 


与 群集 内 DNS 一 样 ， 许 多 安装 方法 都 有 对 应 启用 RBAC 的 途径 。 


Minikube 


如 果 您 正在 使 用 Minikube， 请 使 用 以 下 命令 启动 群集 : 


minikube start --extra-config-apiserver.Authorization.Mode-RBAC 


hack/local-cluster-up.sh 


如 果 使 用 hack/local-up-cluster.sh 脚本 ， 请 使 用 以 下 命令 启动 群集 : 


AUTHORIZATION MODE-Node,RBAC hack/local-up-cluster.sh -0 


BREA 
许多 云 提 供 商 为 你 启用 了 RBAC 的 新 集群 。 有 关 详 细 信 息 ， 请 查阅 你 的 提供 商 的 文 
档 。 
-— . 
4C Service Catalog 
集群 和 Helm 配 置 正确 ， 36 Service Catalog 很 简单 : 


helm install svc-cat/catalog \ 
--name catalog --namespace catalog 


4C Service Catalog CLI ¥ 7 35; 


按照 适用 于 操作 系统 的 说 明 安 装 svcat。 二 进 制 文件 可 以 单独 使 用 ， 也 可 以 作为 
kubectl 插 件 使 用 。 


MacOS 


curl -sLO https://download.svcat.sh/cli/latest/darwin/amd64/svca 
t 

chmod +x ./svcat 

mv ./svcat /usr/local/bin/ 

svcat version --client 


Linux 


curl -sLO https://download.svcat.sh/cli/latest/linux/amd64/svcat 
chmod +x ./svcat 

mv ./svcat /usr/local/bin/ 

svcat version --client 


Windows 


下 面 的 片段 仅 在 当前 会 话 的 PATH 添加 一 个 路 径 。 后 续 使 用 需要 将 它 相 应 的 路 径 永 
久 添 加 到 PATH 中 。 


iwr 'https://download.svcat.sh/cli/latest/windows/amd64/svcat.ex 
e' -UseBasicParsing -OutFile svcat.exe 

mkdir -f ~\bin 

$env:PATH += ";${pwd}\bin" 

svcat version --client 


手动 方式 


1. 对 应 操作 系统 下 载 相应 的 二 进 制 文件 : 
o macOS: https://download.svcat.sh/cli/latest/darwin/amd64/svcat 
o Windows: https://download.svcat.sh/cli/latest/windows/amd64/svcat.exe 
o Linux: https://download.svcat.sh/cli/latest/linux/amd64/svcat 

2. 使 二 进 制 文件 可 执行 。 

3. 将 二 进 制 文件 移动 到 PATH 相 应 的 目录 。 


插件 方式 使 用 客户 端 
要 将 svcat 用 作 插 件 ， 请 在 下 载 后 运行 以 下 命令 : 


$ ./svcat install plugin 
Plugin has been installed to ~/.kube/plugins/svcat. Run kubectl 
plugin svcat --help for help using the plugin. 


当 作 为 插件 运行 时 ， 这 些 命令 与 添加 全 局 kubectl 配 置 标志 相同 。 其 中 一 个 例外 是 ， 
ed says m A ， 所 以 不 要 使 用 --flag ,必须 指定 -- 
flag-true ° 
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Kubernetes 作 为 一 个 容器 编排 调度 引擎 ， 资 源 调度 它 的 最 基本 也 是 最 重要 的 功 
能 ， 这 一 节 中 我 们 将 着 nce ee MM 源 调度 的 。 


Kubernetes 中 有 一 个 叫做 kube-scheduler 的 组 件 ， 该 组 件 就 是 专门 监听 kube- 
apiserver 中 是 否 有 还 未 调度 到 node 上 的 pod， 再 通过 特定 的 算法 为 pod 指 定 分 派 
node 运 行 。 


Kubernetes 中 的 众多 资源 类 型 ， 例 ` DaemonSet ` StatefulSet= if 
已 经 定义 了 Pod 运 行 的 一 些 默 认 调 度 策略 ， 但 是 如 果 我 们 细心 的 根据 nodesa 或 者 pod 
N i 同属 性 ， 分 别 为 它们 打上 标签 之 后 ， 我 们 将 发 现 Kubernetes 中 的 高 级 调度 策略 

么 强大 。 当 然 如 果 要 实现 动态 的 资源 调度 ， 即 pod 已 经 调度 到 某 些 节点 上 后 ， 
DAMNUM 原因 ， 想 要 让 pod 重 新 调度 到 其 它 节点 。 


考虑 以 下 两 种 情况 : 


e 集群 中 有 新 增 节点 ， 想 要 让 集群 中 的 节点 的 资源 利用 率 比 较 均 衡 一 些 ， 想 要 将 
一 些 高 负载 的 节点 上 的 pod 驱 逐 到 新 增 节 点 上 ， 这 是 kuberentes 的 scheduer 所 
不 支持 的 ， 需 要 使 用 如 rescheduler 这 样 的 插件 来 实现 。 

e 想 要 运行 一 些 大 数据 应 用 ， 设 计 到 资源 分 片 ，pod 需 要 与 数据 分 布 达 到 一 致 均 
衡 ， 避 免 个 别 节点 处 理 大 量 数据 ， 而 其 它 节点 闲置 导致 整个 作业 延迟 ， 这 时 候 
可 以 考虑 使 用 kube-arbitritor 。 
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> fu 
用 户 指南 
该 章节 主要 记录 kubernetes 使 用 过 程 中 的 一 些 配 置 技巧 和 操作 。 


e 配置 Pod 的 liveness 和 readiness 探 针 
e 管理 集群 中 的 TLS 


Copyright © jimmysong.io 2017-2018 all right reserved > powered by 
GitbookUpdated at 2018-05-09 14:15:47 


资源 配置 


Kubernetes 中 的 各 个 Object 的 配置 指南 。 
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配置 Pod 的 liveness 和 readiness 探 针 


当 你 使 用 kuberentes 的 时 候 ， 有 没有 遇 到 过 Pod 在 启动 后 一 会 就 挂 掉 然 后 又 重新 户 
动 这 样 的 恶性 循环 ?你 有 没有 想 过 kubernetes 是 如 何 检 测 pod 是 否 还 存活 ? BRE 
器 已 经 启动 ， 但 是 kubernetes 如 何 知 道 容器 的 进程 是 否 准 备 好 对 外 提供 服务 了 呢 ? 
让 我 们 通过 kuberentes 官 网 的 这 篇 文章 Configure Liveness and Readiness 


Probes， 来 一 探究 竟 。 
本 文 将 向 展示 如 何 配置 容器 的 存活 和 可 读 性 探 针 。 


Kubelet 使 用 liveness probe (存活 探 针 ) 来 确定 何 时 重启 容器 。 例 如 ， 当 应 用 程序 
处 于 运行 状态 但 无 法 做 进一步 操作 ， po 414428 #1 deadlock | 重启 处 于 该 
状态 下 的 容器 ， 使 应 用 程序 在 存在 bug 的 情况 下 依然 能 够 继续 运行 下 去 ( 谁 的 程序 
还 没 几 个 bug 呢 ) 。 


Kubelet 使 用 readiness probe (就 绪 探 针 ) 来 确定 容器 是 否 已 经 就 绪 可 以 接受 流 
量 。 只 有 当 Pod 中 的 容器 都 处 于 就 绪 状 态 时 kubelet 才 会 认定 该 Pod 处 于 就 绪 状 态 。 
该 信号 的 作用 是 控制 哪些 Pod 应 该 作为 service 的 后 端 。 如 果 Pod 处 于 非 就 绪 状 态 ， 
那么 它们 将 会 被 从 service 的 load balancer 中 移 除 。 


定义 liveness 命 令 
许多 长 时 间 运 行 的 应 用 程序 最 终 会 转换 到 broken 状 态 ， 除 非 重 新 启动 ， 否 则 无 法 恢 
复 。Kubernetes 提 供 了 liveness probe 来 检测 和 补救 这 种 情况 。 


在 本 次 练习 将 基于 ger.io/google_containers/busybox 镜像 创建 运行 一 个 容 
器 的 Pod。 以 下 是 Pod 的 配置 文件 exec-liveness.yaml 


apiVersion: v1 
kind: Pod 
metadata: 
labels: 
test: liveness 
name: liveness-exec 
spec: 
containers: 
- name: liveness 
args: 
- /bin/sh 
- -C 
- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 6 
00 
image: gcr.io/google_containers/busybox 
livenessProbe: 
exec: 
command: 
- cat 
- /tmp/healthy 
initialDelaySeconds: 5 
periodSeconds: 5 


该 配置 文件 给 Pod 配 置 了 一 个 容器 。 periodSeconds 规定 Kubelet 要 每 隔 5 秒 执行 
一 次 liveness probe。 initialDelaySeconds 告诉 kubelet 在 第 一 次 执行 probe 之 
前 要 的 等 待 5 秒 钟 。 探 针 检 测 命令 是 在 容器 中 执行 cat /tmp/healthy 命令 。 如 
果 命 令 执行 成 功 ， 将 返回 0，kubelet 就 会 人 该 容器 是 活着 的 并 且 很 健康 。 如 果 返 
回 非 0 值 ，kubelet 就 会 杀 掉 这 个 容器 并 重启 


/bin/sh -c "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; s 
leep 600" 


在 容器 生命 的 最 初 30 秒 内 有 一 个 /tmp/healthy 文件 ， 在 这 30 秒 内 cat 
suc M 命令 会 返回 一 个 成 功 的 返回 码 。30 秒 后 ， cat /tmp/healthy 将 
返回 失败 的 返回 码 o 


创建 Pod : 


kubectl create -f https://k8s.io/docs/tasks/configure-pod-contai 
ner/exec- liveness. yaml 


在 30 秒 内 ， 查 看 Pod 的 event : 


kubectl describe pod liveness-exec 


结果 显示 没有 失败 的 liveness probe : 


FirstSeen LastSeen Count From SubobjectPath 
Type Reason Message 

24s 24s 1 {default-scheduler } No 

rmal Scheduled Successfully assigned liveness-exec to wor 

kero 

23s 23s 1 {kubelet workerO} spec.containers{livene 

ss} Normal Pulling pulling image "gcr.io/google conta 

iners/busybox" 

23s 23s 1 {kubelet workerO) spec.containers{livene 

ss} Normal Pulled Successfully pulled image "gcr.io/ 

google containers/busybox" 

23s 23s 1 {kubelet workerO} spec.containers{livene 

ss} Normal Created Created container with docker id 8 

6849c15382e; Security: [Seccomp=unconf ined | 

23s 23s 1 {kubelet workerO) spec.containers{livene 

ss} Normal Started Started container with docker id 8 

6849c15382e 


启动 35 秒 后 ， 再 次 查看 pod 的 event : 


kubectl describe pod liveness-exec 


在 最 下 面 有 一 条 信息 显示 liveness probe 失 败 ， 容 器 被 删 掉 并 重新 创建 。 


FirstSeen LastSeen Count From SubobjectPath 


Type Reason Message 
37s 37s 1 {default-scheduler } No 
rmal Scheduled Successfully assigned liveness-exec to wor 
kero 
36s 36s 1 {kubelet workerO) spec.containers{livene 
ss} Normal Pulling pulling image "gcr.io/google_conta 
iners/busybox" 
36s 36s 1 {kubelet workerO} spec.containers{livene 
ss} Normal Pulled Successfully pulled image "gcr.io/ 
google containers/busybox" 
36s 36s 1 {kubelet worker®O} spec.containers{livene 
ss} Normal Created Created container with docker id 8 
6849c15382e; Security: [Seccomp=unconfined | 
36s 36s 1 {kubelet workerO) spec.containers{livene 
ss} Normal Started Started container with docker id 8 
6849c15382e 
2s 2s 1 {kubelet workerO} spec.containers{livene 
ss} Warning Unhealthy Liveness probe failed: cat: can't 


open '/tmp/healthy': No such file or directory 
再 等 30 秒 ， 确 认 容 器 已 经 重启 : 
kubectl get pod liveness-exec 


从 输出 结果 来 RESTARTS 14017 ° 


NAME READY STATUS RESTARTS AGE 
liveness-exec 1/1 Running 1 1m 


定义 一 个 liveness HTTP 请 求 


我 们 还 可 以 使 用 HTTP GET 请 求 作为 liveness probe。 下 面 是 一 个 基 
于 gcr.io/google containers/liveness 镜像 运行 了 一 个 容器 的 Pod 的 例 
子 http-liveness. yaml 


apiVersion: v1 
kind: Pod 
metadata: 
labels: 
test: liveness 
name: liveness-http 
spec: 
containers: 
- name: liveness 
args: 
- /server 
image: gcr.io/google containers/liveness 
livenessProbe: 
httpGet: 
path: /healthz 
port: 8080 
httpHeaders: 
- name: X-Custom-Header 
value: Awesome 
initialDelaySeconds: 3 
periodSeconds: 3 


该 配置 文件 只 定义 了 一 个 容器 ， livenessProbe 指定 kubelete 需 要 每 隔 3 秒 执行 
一 次 liveness probe » initialDelaySeconds 指定 kubelet 在 该 执行 第 一 次 探测 之 
前 需要 等 待 3 秒 钟 。 该 探 针 将 向 容器 中 的 server 的 8080 端 口 发 送 一 个 HTTP GET 请 
求 。 如 果 server 的 /healthz 路 径 的 handler 返 回 一 个 成 功 的 返回 码 ，kubelet 就 会 
认定 该 容器 是 活着 的 并 且 很 健康 。 如 果 返 回 失败 的 返回 码 ，kubelet 将 杀 掉 该 容器 并 
重启 它 。 


任何 大 于 200 小 于 400 的 返回 码 都 会 认定 是 成 功 的 返回 码 。 其 他 返回 码 都 会 被 认为 是 
失败 的 返回 码 。 


查看 该 server 的 源码 : server.go. 


最 开始 的 10 秒 该 容器 是 活着 的 ， /healthz handler 返 回 200 的 状态 码 。 这 之 后 将 
返回 500 的 返回 码 。 


http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http. 
Request) { 
duration :- time.Now().Sub(started) 
if duration.Seconds() » 10 ( 
w.WriteHeader(500) 
w.Write([]byte(fmt.Sprintf("error: %v", duration.Seconds( 


33] 
) else { 
w.WriteHeader (200) 
w.Write([]byte("ok")) 
}) 


0 


容器 启动 3 秒 后 ，Kkubelet 开 始 执 行 健康 检查 。 第 一 次 健康 监测 会 成 功 ， 但 是 10 秒 
后 ， 健 康 检查 将 失败 ，kubelet 将 杀 掉 和 重启 容器 。 


创建 一 个 Pod 来 测试 一 下 HTTP liveness 检 测 : 


kubectl create -f https://k8s.io/docs/tasks/configure-pod-contai 
ner/http-liveness.yaml 


After 10 seconds, view Pod events to verify that liveness probes have failed and 
the Container has been restarted: 


10 秒 后 ， 查 看 Pod 的 event， 确 认 liveness probe 失 败 并 重启 了 容器 。 


kubectl describe pod liveness-http 


定义 TCP liveness4& 4t 


P = # liveness Pao aen Socket ° 使 用 此 配置 ，kubelet 将 尝试 在 指定 端口 上 
打开 容器 的 套 接 字 。 如 果 可 以 建立 连接 ， 容 器 被 认为 是 健康 的 ， 如 果 不 能 就 认为 是 
失败 的 。 


apiVersion: v1 
kind: Pod 
metadata: 
name: goproxy 
labels: 
app: goproxy 
spec: 
containers: 
- name: goproxy 
image: gcr.io/google containers/goproxy:0.1 
ports: 
- containerPort: 8080 
readinessProbe: 
tcpSocket: 
port: 8080 
initialDelaySeconds: 5 
periodSeconds: 10 
livenessProbe: 
tcpSocket: 
port: 8080 
initialDelaySeconds: 15 
periodSeconds: 20 


如 您 所 见 ，TCP 检 查 的 配置 Si ul 相似 。 此 示例 同时 使 用 了 readiness 和 
liveness probe。 容器 局 秒 钟 ，kubelet 将 发 送 第 一 个 readiness probe。 这 将 
尝试 连接 到 端 ee 。 如 果 探 测 成 功 ， 则 该 pod 将 被 标记 为 就 


绪 。Kubelet 将 每 隔 10 秒 钟 执行 一 次 该 检查 。 


& T readiness probe 之 外 ， 该 配置 还 包括 liveness probe » 容器 启动 15 秒 后 ， 
ie 运行 第 一 个 liveness probe » 就 像 readiness probe 一 样 ， 这 将 尝试 连接 到 
goproxy 容 器 上 的 8080 端 口 。 如 果 |iveness probe 失 败 ， 容 器 将 重新 启动 。 


使 用 命名 的 端口 


可 以 使 用 命名 的 ContainerPort 作 为 HTTP 或 TCP liveness 检 查 : 


ports: 

- name: liveness-port 
containerPort: 8080 
hostPort: 8080 


livenessProbe: 
httpGet: 
path: /healthz 
port: liveness-port 


定义 readiness 探 针 


有 时 ， 应 用 程序 ee UN MM UL iQ E XB abd 

间 加 载 大 量 数据 或 配置 文件 。 在 这 种 情况 下 ， 你 不 想 杀 死 应 用 程序 ， 但 你 也 不 想 发 

送 请 求 。Kubernetes 提 供 了 readiness eee * 减轻 这 些 情况 的 容 
器 可 以 报告 自己 还 没有 准备 ， 不 能 处 理 Kubernetes 服 务 发 送 过 来 的 流 


Readiness probe #4 & Æ sKliveness probe 很 像 。 唯 一 的 不 同 是 使 用 


readinessProbe 而 不 是 livenessProbe 。 


readinessProbe: 
exec: 
command: 
- cat 
- /tmp/healthy 
initialDelaySeconds: 5 
periodSeconds: 5 


Readiness probes HTTPAe TCP $5 2& 3 2$ Ac & sKliveness probe— 7€ ° 


Readiness% livenss probe 可 以 并 行 用 于 同一 容器 。 使 用 两 者 可 以 确保 流量 无 法 到 
达 未 准备 好 的 容器 ， 并 且 容 器 在 失败 时 重新 启动 。 


配置 Probe 
Probe 中 有 很 多 精确 和 详细 的 配置 过 它们 你 能 准确 的 控制 liveness 和 readiness 
检查 : 

e initialDelaySeconds : 容器 启动 后 第 一 次 执行 探测 是 需要 等 待 多 少 秒 。 


e periodSeconds ATARI OIA © ROB ， 最 小 1 秒 。 


e timeoutSeconds : 探测 超时 时 间 。 默 认 1 秒 ， 最 小 1 秒 。 

e successThreshold : 探测 失败 后 ， 了 最少 连续 探测 成 功 多 少 次 才 被 认定 为 成 
功 。 默 认 是 1。 对 于 liveness 必 须 是 1。 最 小 值 是 1。 

e failureThreshold : 探测 成 功 后 ， 最 少 连 续 探 测 失 败 多 少 次 才 被 认定 为 失 
败 。 默 认 是 3。 最 小 值 是 1。 


HTTP probe 中 可 以 给 httpGet 设置 其 他 配置 项 


e host :连接 的 主机 名 ， 默 认 连 接 到 pod 的 IP。 你 可 能 想 在 http header 中 设 
置 "Host" 而 不 是 使 用 |P。 

e scheme : 连接 使 用 的 Schema， 默 认 HTTP ° 

e path :访问 的 HTTP server 的 path 。 

e httpHeaders : 自 定 义 请 求 的 header。HTTP 运 行 重复 的 header 。 

e port :访问 的 容器 的 端口 名 字 或 者 端口 号 。 端 口号 必须 介 于 1 和 65525 之 
间 。 


对 于 HTTP 探 测 器 ，kubelet 向 指定 的 路 径 和 端口 发 送 HTTP 请 求 以 执行 检查 。 
Kubelet 将 probe 发 送 到 容器 的 IP 地址 ， 除 非 地 址 被 httpGet 中 的 可 选 host 字段 
和 窗 盖 。 在 大 多 数 情 况 下 ， 你 不 想 设 置 主 机 字段 。 有 一 种 情况 下 你 可 以 设置 它 。 假 
设 容器 在 127.0.0.1 上 侦 听 ， 并 且 Pod 的 hostNetwork 字段 为 true 然后 ， 

在 httpGet 下 的 host 应 该 设置 为 127.0.0.1。 如 果 你 的 pod 依 赖 于 虚拟 主机 ， 这 
可 能 是 更 常见 的 情况 ， 你 不 应 该 是 用 host ， 而 是 应 该 在 httpHeaders 中 设 

置 Host 头 。 


e 关于 Container Probes 的 更 多 信息 
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配置 Pod 的 Service Account 


Service account 为 Pod 中 的 进程 提供 身份 信息 。 


本 文 是 关于 Service Account 的 用 户 指南 ， 管 理 指南 另 见 Service Account 的 集群 
管理 指南 。 


注意 : 本 文档 描述 的 关于 Serivce Account 的 行为 只 有 当 您 按照 Kubernetes 项 目 
建议 的 方式 搭建 起 集群 的 情况 下 才 有 效 。 您 的 集群 管理 员 可 能 在 您 的 集群 中 有 自 定 
义 配 置 ， 这 种 情况 下 该 文档 可 能 并 不 适用 。 


当 您 RAMP) 访问 集群 (例如 使 用 kubectl A) 时 ，apiserver 会 将 您 认证 
为 一 个 特定 的 User Account (目前 通常 是 admin ， 除 非 您 的 系统 管理 员 自 定义 了 

集群 配置 ) ° Pod 容器 中 的 进程 也 可 以 与 apiserver 联系 。 当 它 们 在 联系 apiserver 
的 时 候 ， 它 们 会 被 认证 为 一 个 特定 的 Service Account (例如 default ) ° 


使 用 默认 的 Service Account 访问 API server 


当 您 创建 pod 的 时 候 ， 如 果 您 没有 指定 一 个 service account， 系 统 会 自动 得 在 与 
该 pod 相同 的 namespace 下 为 其 指派 一 个 default service account。 如 果 您 获 
取 刚 创建 的 pod 的 原始 json 或 yaml 信息 (例如 使 用 kubectl get 
pods/podename -o yaml TA) ， 您 将 看 到 spec.serviceAccountName 字段 已 


经 被 设置 为 automatically set 。 


您 可 以 在 pod 中 使 用 自动 挂 载 的 service account 凭证 来 访问 API， 如 Accessing 
the Cluster 中 所 描述 。 


Service account 是 否 能 够 取得 访问 API 的 许可 取决 于 您 使 用 的 授权 插件 和 策略 。 


在 1.6 以 上 版 本 中 ， 您 可 以 选择 取消 为 service account A HR API Hit RF 
在 service account 中 设置 automountServiceAccountToken: false 


apiVersion: v1 
kind: ServiceAccount 
metadata: 
name: build-robot 
automountServiceAccountToken: false 


在 1.6 以 上 版 本 中 ， 您 也 可 以 选择 只 取消 单个 pod 的 API 凭证 自动 挂 载 : 


apiVersion: vi 

kind: Pod 

metadata: 
name: my-pod 

spec: 
serviceAccountName: build-robot 
automountServiceAccountToken: false 


如 果 在 pod 和 service account 中 同时 设置 了 automountServiceAccount Token 
, pod 设置 中 的 优先 级 更 高 。 


使 用 多 个 Service Account 


每 个 namespace 中 都 有 一 个 上 默认 的 叫做 default 的 service account 资源 。 


您 可 以 使 用 以 下 命令 列 出 namespace 下 的 所 有 serviceAccount 资源 。 


$ kubectl get serviceAccounts 
NAME SECRETS AGE 
default 1 1d 


您 可 以 像 这 样 创建 一 个 ServiceAccount * & : 


$ cat > /tmp/serviceaccount.yaml <<EOF 
apiVersion: vi 
kind: ServiceAccount 
metadata: 
name: build-robot 
EOF 
$ kubectl create -f /tmp/serviceaccount.yaml 
serviceaccount "build-robot" created 


如 果 您 看 到 如 下 的 service account 对 象 的 完整 输出 信息 : 


$ kubectl get serviceaccounts/build-robot -o yaml 
apiVersion: vi 
kind: ServiceAccount 
metadata: 

creationTimestamp: 2015-06-16T00:12:59Z 

name: build-robot 

namespace: default 

resourceVersion: "272500" 

selfLink: /api/vi/namespaces/default/serviceaccounts/build-rob 
ot 

uid: 721ab723-13bc-11e5-aec2-42010af0021e 
secrets: 
- name: build-robot-token-bvbk5 


然后 您 将 看 到 有 一 个 token 已 经 被 自动 创建 ， 并 被 service account 引用 。 
您 可 以 使 用 授权 插件 来 设置 service account 的 权限 。 


设置 非 默 认 的 service account， 只 需要 在 pod 的 spec.serviceAccountName 字 
段 中 将 name 设 置 为 您 想 要 用 的 service account 名 字 即 可 。 


在 pod 创建 之 初 service account 就 必须 已 经 存在 ， 否 则 创建 将 被 拒绝 。 
您 不 能 更 新 已 创建 的 pod 的 service account。 


您 可 以 清理 service account， 如 下 所 示 : 


$ kubectl delete serviceaccount/build-robot 


手动 创建 service account 的 API token 


假设 我 们 已 经 有 了 一 个 如 上 文 提 到 的 名 为 ”build-robot 的 service account * 4&1] + 
动 创建 一 个 新 的 secret 。 


$ cat > /tmp/build-robot-secret.yaml ««EOF 
apiVersion: vi 
kind: Secret 
metadata: 

name: build-robot-secret 

annotations: 

kubernetes.io/service-account.name: build-robot 

type: kubernetes.io/service-account-token 
EOF 
$ kubectl create -f /tmp/build-robot-secret.yaml 
secret "build-robot-secret" created 


现在 您 可 以 确认 下 新 创建 的 secret 取代 了 "build-robot" 这 个 service account 原来 
的 API token ° 


所 有 已 不 存在 的 service account 的 token 将 被 token controller 清理 掉 。 


$ kubectl describe secrets/build-robot-secret 


Name: build-robot-secret 
Namespace: default 
Labels: <none> 


Annotations:  kubernetes.io/service-account.name-build-robot,kub 
ernetes.io/service-account.uid-z870ef2a5-35cf-11e5-8d06-005056b45 
392 


Type: kubernetes.io/service-account-token 


ca.crt: 1220 bytes 
token: 
namespace: 7 bytes 


注意 该 内 容 中 的 token RAST ° 


为 service account 添加 ImagePullSecret 


首先 ， 创 建 一 个 imagePullSecret， 详 见 这 里 。 
然后 ， 确 认 已 创建 。 如 : 
$ kubectl get secrets myregistrykey 


NAME TYPE DATA AGE 
myregistrykey kubernetes.io/.dockerconfigjson 1 1d 


然后 ， 修 改 namespace 中 的 默认 service account 使 用 该 secret 作为 
imagePullSecret ° 


kubectl patch serviceaccount default -p '{"imagePullSecrets": 
"name": "myregistrykey"}]}' 


Vi 交互 过 程 中 需要 手动 编辑 : 


$ kubectl get serviceaccounts default -0 yaml > ./sa.yaml 
$ cat sa.yaml 
apiVersion: vi 
kind: ServiceAccount 
metadata: 
creationTimestamp: 2015-08-07T22:02:39Z 
name: default 
namespace: default 
resourceVersion: "243024" 
selfLink: /api/vi/namespaces/default/serviceaccounts/default 
uid: 052fbOf4-3d50-11e5-b066-42010af0d7b6 
secrets: 
- name: default-token-uudge 
$ vi sa.yaml 
[editor session not shown] 
[delete line with key "resourceVersion"] 
[add lines with "imagePullSecret:"] 
$ cat sa.yaml 
apiVersion: vi 
kind: ServiceAccount 
metadata: 
creationTimestamp: 2015-08-07T22:02:39Z 
name: default 
namespace: default 
selfLink: /api/vi/namespaces/default/serviceaccounts/default 
uid: 052fbOf4-3d50-11e5-b066-42010af0d7b6 
secrets: 
- name: default-token-uudge 
imagePullSecrets: 
- name: myregistrykey 
$ kubectl replace serviceaccount default -f ./sa.yaml 
serviceaccounts/default 


现在 ， 所 有 当前 namespace 中 新 创建 的 pod 的 spec 中 都 会 增加 如 下 内 容 : 


spec: 
imagePullSecrets: 
- name: myregistrykey 


[t 
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Secret 配置 


Secret 对 象 类 型 用 来 保存 敏感 信息 ， 例 如 密码 、OAuth 令 牌 和 ssh key » Hà 
言 息 放 在 secret 中 比 放 在 pod 的 定义 中 或 者 docker 镜像 中 来 说 更 加 安全 和 
灵活 。 参 阅 Secret 设计 文档 获取 更 多 详细 信息 。 


Secret 概览 


Secret 是 一 种 包含 少量 敏感 信息 例如 密码 、token 或 key 的 对 象 。 这 样 的 信息 可 能 
会 被 放 在 Pod spec 中 或 者 镜像 中 ; 将 其 放 在 一 个 secret 对 象 中 可 以 更 好 地 控制 它 
的 用 途 ， 并 降低 意外 暴露 的 风险 。 


用 户 可 以 创建 secret， 同 时 系统 也 创建 了 一 些 secret ^ 


要 使 用 secret > pod 需要 引用 secret » Pod 可 以 用 两 种 方式 使 用 secret : 作为 
volume 中 的 文件 被 挂 载 到 pod 中 的 一 个 或 者 多 个 容器 里 ， 或 者 当 kubelet 为 pod 
拉 取 镜像 时 使 用 。 


内 置 Secret 


Service Account 使 用 API 凭证 自动 创建 和 附加 secret 


Kubernetes 自动 创建 包含 访问 API 凭据 的 secret， 并 自动 修改 您 的 pod 以 使 用 此 
类 型 的 secret ° 


如 果 需 要 ， 可 以 禁用 或 覆盖 自动 创建 和 使 用 API 赁 据 。 但 是 ， 如 果 您 需要 的 只 是 安 
全 地 访问 apiserver， 我 们 推荐 这 样 的 工作 流程 。 


参阅 Service Account 文档 获取 关于 Service Account 如 何 工 作 的 更 多 信息 。 
创建 您 自己 的 Secret 


使 用 kubectl 创建 Secret 


假设 有 些 pod 需要 访问 数据 库 。 这 些 pod 需要 使 用 的 用 户 名 和 密码 在 您 本 地 机 器 
的 ./username.txt 和 ./password.txt 文件 里 。 


# Create files needed for rest of example. 
$ echo -n "admin" > ./username.txt 
$ echo -n "1f2d1e2e67df" > ./password.txt 


kubectl create secret 命令 将 这 些 文件 打包 到 一 个 Secret 中 并 在 APl server 
中 创建 了 一 个 对 象 。 


$ kubectl create secret generic db-user-pass --from-file=./usern 
ame.txt --from-file=./password.txt 
secret "db-user-pass" created 


您 可 以 这 样 检查 刚 创建 的 secret : 


$ kubectl get secrets 


NAME TYPE DATA 
AGE 

db-user-pass Opaque 2 
51s 


$ kubectl describe secrets/db-user-pass 


Name: db-user-pass 
Namespace: default 
Labels: <none> 
Annotations: <none> 

Type: Opaque 

Data 

password.txt: 12 bytes 
username.txt: 5 bytes 


请 注意 ， 默 认 情 况 下 ， get 和 describe 命令 都 不 会 显示 文件 的 内 容 。 这 是 为 
了 防止 将 secret 中 的 内 容 被 意外 暴露 给 从 终端 日 eer | SERENA © 


请 参阅 解码 secret 了 解 如 何 查看 它们 的 内 容 。 


手动 创建 Secret 
您 也 可 以 先 以 json 或 yam 格式 在 文件 中 创建 一 个 secret 对 象 ， 然 后 创建 该 对 象 。 


每 一 项 必须 是 base64 编码 : 


$ echo -n "admin" | base64 
YWRtaW4- 

$ echo -n "1f2d1e2e67df" | base64 
MWYyZDF1MmU2N2Rm 


现在 可 以 像 这 样 写 一 个 secret 对 象 : 


apiVersion: v1 

kind: Secret 

metadata: 
name: mysecret 

type: Opaque 

data: 
username: YWRtaW4- 
password: MWYyZDF1MmU2N2Rm 


数据 字段 是 一 个 映射 。 它 的 键 必 须 匹 配 DNS_SUBDOMAIN， 前 导 点 也 是 可 以 的 。 
这 些 值 可 以 是 任意 数据 ， 使 用 base64 进行 编码 。 


使 用 kubectl create 创建 secret : 


$ kubectl create -f ./secret.yaml 
secret "mysecret" created 


编码 注意 : secret 数据 的 序列 化 JSON 和 YAML 值 使 用 base64 编码 成 字符 囊 。 

换行 符 在 这 些 字 符 串 中 无 效 ， 必 须 省 略 。 当 在 Darwin/OS X 上 使 用 base64 实用 
程序 时 ， 用 户 应 避免 使 用 -b 选项 来 拆 分 长 行 。 另 外 ， 对 于 Linux 用 户 如 果 -w 
选项 不 可 用 的 话 ， 应 该 添加 选项 -w 0 到 base64 命令 或 管道 base64 | tr - 
qdRNni il ° 


解码 Secret 


可 以 使 用 kubectl get secret 命令 获取 secret。 例 如 ， 获 取 在 上 一 节 中 创建 的 
secret : 


$ kubectl get secret mysecret -o yaml 
apiVersion: vi 
data: 
username: YWRtaW4- 
password: MWYyZDF1MmU2N2Rm 
kind: Secret 
metadata: 
creationTimestamp: 2016-01-22T18:41:56Z 
name: mysecret 
namespace: default 
resourceVersion: "164619" 
selfLink: /api/vi/namespaces/default/secrets/mysecret 
uid: cfee02d6-c137-11e5-8d73-42010af 00002 
type: Opaque 


$ echo "MWYyZDF1MmU2N2Rm" | base64 --decode 
1f2d1e2e67df 


使 用 Secret 


Secret 可 以 作为 数据 卷 被 挂 载 ， 或 作为 环境 变量 暴露 出 来 以 供 pod 中 的 容器 使 用 。 
它们 也 可 以 被 系统 的 其 他 部 分 使 用 ， 而 不 直接 暴露 在 pod 内 。 例 如 ， 它 们 可 以 保存 
凭据 ， 系 统 的 其 他 部 分 应 该 用 它 来 代表 您 与 外 部 系统 进行 交互 。 


在 Pod 中 使 用 Secret 文件 
在 Pod 中 的 volume 里 使 用 Secret : 


1. 创建 一 个 secret 或 者 使 用 已 有 的 secret。 多 个 pod 可 以 引用 同一 个 secret 。 
2. 修改 您 的 pod 的 定义 在 spec.volumes[] 下 增加 一 个 volume。 可 以 给 这 个 
volume 随意 命名 ， 它 的 spec.volumes[].secret.secretName 必须 等 于 
secret 对 象 的 名 字 。 
3. 将 spec.containers[].volumeMounts[] 加 到 需要 用 到 该 secret 的 容器 
中 。 指 定 spec.containers[].volumeMounts[].readonly = true 和 
spec.containers[].volumeMounts[].mountPath 为 您 想 要 该 secret 出 现 
的 尚未 使 用 的 目录 。 
4. 修改 您 的 镜像 并 且 或 者 命令 行 让 程序 从 该 目录 下 寻找 文件 。Secret 的 
data 映射 中 的 每 一 个 键 都 成 为 了 mountPath 下 的 一 个 文件 名 。 


这 是 一 个 在 pod 中 使 用 volume 4 # secret 的 例子 : 


apiVersion: vi 
kind: Pod 
metadata: 
name: mypod 
spec: 
containers: 
- name: mypod 
image: redis 
volumeMounts: 
- name: foo 
mountPath: "/etc/foo" 
readOnly: true 
volumes: 
- name: foo 
secret: 
secretName: mysecret 


您 想 要 用 的 每 个 secret 都 需要 在 spec.volumes 中 指明 。 


如 果 pod 中 有 多 个 容器 ， 每 个 容器 都 需要 自己 的 volumeMounts 配置 块 ， 但 是 每 


个 secret 只 需要 一 个 spec.volumes ° 


您 可 以 打包 多 个 文件 到 一 个 secret 中 ， 或 者 使 用 的 多 个 secret， 怎 样 方便 就 怎样 
o 


向 特性 路 径 映 射 secret 2 4A 


我 们 还 可 以 控制 Secret key 映射 在 volume 中 的 路 径 。 您 可 以 使 用 
spec.volumes[].secret.items 字段 修改 每 个 key 的 目标 路 径 : 


apiVersion: v1 
kind: Pod 
metadata: 
name: mypod 
spec: 
containers: 
- name: mypod 
image: redis 
volumeMounts: 
- name: foo 
mountPath: "/etc/foo" 
readOnly: true 
volumes: 
- name: foo 
secret: 
secretName: mysecret 
items: 
- key: username 
path: my-group/my-username 


将 会 发 生 什么 呢 : 


e username secret 存储 在 /etc/foo/my-group/my-username 文件 中 而 不 
是 /etc/foo/username 中 。 


e password secret 没有 被 影射 


如 果 使 用 了 spec.volumes[].secret.items ， 只 有 在 items 中 指定 的 key 被 
影射 。 要 使 用 secret 中 所 有 的 key， 所 有 这 些 都 必须 列 在 items 字段 中 。 所 有 
列 出 的 密 铀 必须 存在 于 相应 的 secret 中 。 否 则 ， 不 会 创建 卷 。 


Secret 文件 权限 


您 还 可 以 指定 secret 将 拥有 的 权限 模式 位 文件 。 如 果 不 指定 ， 默 认 使 用 0644 ° 
您 可 以 为 整个 保密 卷 指定 默认 模式 ， 如 果 需 要 ， 可 以 覆盖 每 个 密 钥 。 


apiVersion: v1 
kind: Pod 
metadata: 
name: mypod 
spec: 
containers: 
- name: mypod 
image: redis 
volumeMounts: 
- name: foo 
mountPath: "/etc/foo" 
volumes: 
- name: foo 
secret: 
secretName: mysecret 
defaultMode: 256 


RG > secret 将 被 挂 载 到 /etc/foo 目录 ， 所 有 通过 该 secret volume 4 KEI 
的 文件 的 权限 都 是 0400 。 


请 注意 ，JSON 规范 不 支持 八进制 符号 ， 因 此 使 用 256 值 作为 0400 权限 。 如 果 您 
使 用 yaml 而 不 是 json 作为 pod， 则 可 以 使 用 八进制 符号 以 更 自然 的 方式 指定 权 
限 。 


您 还 可 以 是 用 映射 ， 如 上 一 个 示例 ， 并 为 不 同 的 文件 指定 不 同 的 权限 ， 如 下 所 示 : 


apiVersion: v1 
kind: Pod 
metadata: 
name: mypod 
spec: 
containers: 
- name: mypod 
image: redis 
volumeMounts: 
- name: foo 
mountPath: "/etc/foo" 
volumes: 
- name: foo 
secret: 
secretName: mysecret 
items: 
- key: username 
path: my-group/my-username 
mode: 511 


在 这 种 情况 下 ， 导 致 /etc/foo/my-group/my-username 的 文件 的 权限 值 为 
0777 ° H F JSON 限制 ， 必 须 以 十 进 制 格式 指定 模式 。 


请 注意 ， 如 果 稍 后 阅读 此 权限 值 可 能 会 以 十 进 制 格式 显示 。 
M Volume 中 消费 secret 值 


在 挂 载 的 secret volume 的 容器 内 ，secret key 将 作为 文件 ， 并 且 secret 的 值 使 用 
base-64 解码 并 存储 在 这 些 文件 中 。 这 是 在 上 面 的 示例 容器 内 执行 的 命令 的 结果 : 


$ ls /etc/foo/ 

username 

password 

$ cat /etc/foo/username 
admin 

$ cat /etc/foo/password 
1f2d1e2e67df 


容器 中 的 程序 负责 从 文件 中 读 取 secret 。 

挂 载 的 secret 被 自动 更 新 

当 已 经 在 volume 中 消 被 消费 的 secret 被 更 新 时 ， 被 映射 的 key 也 将 被 更 新 。 
Kubelet 在 周期 性 同步 时 检查 被 挂 载 的 secret 是 不 是 最 新 的 。 但 是 ， 它 正在 使 用 其 
ATF AM ttl 的 缓存 来 获取 当前 的 secret 值 。 结 果 是 ， 当 secret 被 更 新 的 时 刻 到 将 
新 的 secret 映射 到 pod 的 时 刻 的 总 延迟 可 以 与 kubelet 中 的 secret 缓存 的 kubelet 
sync period + ttl —## -K ° 

Secret 作为 环境 变量 

将 secret 作为 pod 中 的 环境 变量 使 用 : 


1. 创建 一 个 secret 或 者 使 用 一 个 已 存在 的 secret。 多 个 pod 可 以 引用 同一 个 


secret ° 
2. 在 每 个 容器 中 修改 您 secret key 的 Pod 定义 ， 为 要 使 用 的 每 个 
secret key 添加 一 个 环境 变量 。 消 费 secret key 的 环境 变量 应 填充 secret 的 名 


， 并 键入 env[x].valueFrom.secretKeyRef ° 
9: EL ew: 令 行 ， 以 便 程序 在 指定 的 环境 变量 中 查找 值 。 


apiVersion: v1 
kind: Pod 
metadata: 
name: secret-env-pod 
spec: 
containers: 
- name: mycontainer 
image: redis 
env: 
- name: SECRET_USERNAME 
valueFrom: 
secretKeyRef: 
name: mysecret 
key: username 
- name: SECRET_PASSWORD 
valueFrom: 
secretKeyRef : 
name: mysecret 
key: password 
restartPolicy: Never 


消费 环境 变量 里 的 Secret 值 
在 一 个 消耗 环境 变量 secret 的 容器 中 ，secret key 作为 包含 secret 数据 的 base-64 


解码 值 的 常规 环境 变量 。 这 是 从 上 面 的 示例 在 容器 内 执行 的 命令 的 结果 : 


$ echo $SECRET_USERNAME 
admin 
$ echo $SECRET_PASSWORD 
1f2d1e2e67df 

使 用 imagePullSecret 


imagePullSecret 是 将 包含 Docker (或 其 他 ) 镜像 注册 表 密 码 的 secret 传递 给 
Kubelet 的 一 种 方式 ， 因 此 可 以 代表 您 的 pod 拉 取 私有 镜像 。 


手动 指定 imagePullSecret 


imagePullSecret 的 使 用 在 镜像 文档 中 说 明 。 


安排 imagePullSecrets 自动 附加 


您 可 以 手动 创建 imagePullSecret， 并 从 serviceAccount 引用 它 。 使 用 该 
serviceAccount 创建 的 任何 pod 和 默认 使 用 该 serviceAccount 的 pod 将 会 将 其 的 
imagePullSecret 字段 设置 为 服务 帐户 的 imagePullSecret 字段 。 有 关 该 过 程 的 详细 
说 明 ， 请 参阅 将 ImagePullSecrets 添加 到 服务 帐户 。 


自动 挂 载 手 动 创建 的 Secret 


手动 创建 的 secret (例如 包含 用 于 访问 github 帐户 的 令 牌 ) 可 以 根据 其 服务 帐户 自 
动 附加 到 pod。 请 参阅 使 用 PodPreset 向 Pod 中 注入 信息 以 获取 该 进程 的 详细 说 
AF o 


详细 
限制 


验证 secret volume 来 源 确保 指定 的 对 象 引 用 实际 上 指向 一 个 类 型 为 Secret 的 对 
象 。 因 此 ， 需 要 在 依赖 于 它 的 任何 pod 之 前 创建 一 个 secret » 


Secret API 对 象 驻 留 在 命名 空间 中 。 它 们 只 能 由 同一 命名 空间 中 的 pod 引用 。 


每 个 secret 的 大 小 限制 为 1MB。 这 是 为 了 防止 创建 非常 大 的 secret 会 耗 尽 
apiserver 和 kubelet 的 内 存 。 然 而 ， 创 建 许 多 较 小 的 secret 也 可 能 耗 尽 内 存 。 更 
全 面 得 限制 secret 对 内 存 使 用 的 更 全 面 的 限制 是 计划 中 的 功能 。 


Kubelet 4x X44 A API server 获取 的 Pod 使 用 secret。 这 包括 使 用 kubectl 创建 的 
任何 pod， 或 间接 通过 replication controller 创建 的 pod。 它 不 包括 通过 kubelet - 
-manifest-url 标志 ， 其 --config 标志 或 其 REST API 创 ed (这 些 不 是 
创建 pod 的 常用 方法 ) 。 


必须 先 创建 secret， 除 非 将 它们 标记 为 可 选项 ， 否 则 必须 在 将 其 作为 环境 变量 在 
pod 中 使 用 之 前 创建 secret。 对 不 存在 的 secret 的 引用 将 阻止 其 启动 。 


通过 secretKeyRef 对 不 存在 于 命名 的 key 中 的 key 进行 引用 将 阻止 该 启动 。 


用 于 通过 envFrom 填充 环境 变量 的 secret， 这 些 环境 变量 具有 被 认为 是 无 效 环境 
变量 名 称 的 key 将 跳 过 这 些 键 。 该 pod 将 被 允许 启动 。 将 会 有 一 个 事件 ， 其 原因 是 
InvalidVariableNames ， 该 消息 将 包含 被 跳 过 的 无 效 键 的 列表 。 该 示例 显示 一 
个 pod， 它 指 的 是 包含 2 个 无 效 键 ，1badkey 和 2alsobad 的 默认 /mysecret 

ConfigMap ° 


$ kubectl get events 


LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOB 
JECT TYPE REASON 
Os Os 1 dapi-test-pod Pod 

Warning InvalidEnvironmentVariabl 
eNames kubelet, 127.0.0.1 Keys [1badkey, 2alsobad] from t 


he EnvFrom secret default/mysecret were skipped since they are c 
onsidered invalid environment variable names. 


Secret 4 Pod 生命 周期 的 联系 


过 API 创建 的 Pod 时 ， 不 会 检查 应 用 的 secret 是 否 存 在 。 一 旦 Pod 被 调度 ， 
kubelet 就 会 尝试 获取 该 secret 的 值 。 如 果 获 取 不 到 该 secret， 或 者 暂时 无 法 与 
API server 建立 连接 ，kubelet 将 会 定期 重 试 。Kubelet 将 会 报告 关于 pod 的 事件 ， 
并 解释 它 无 法 启动 的 原因 。 一 旦 获取 的 secret，Kkubelet 将 创建 并 装载 一 个 包含 它 的 
卷 。 在 安装 所 有 pod 的 卷 之 前 ， 都 不 会 启动 pod 的 容器 。 


4$ FE] R 49] 


1& A El : 包含 ssh 9€ 4157 pod 
创建 一 个 包含 ssh key 的 secret : 


$ kubectl create secret generic ssh-key-secret --from-file=ssh-p 
rivatekey=/path/to/.ssh/id_rsa --from-file=ssh-publickey=/path/t 
o/.ssh/id_rsa.pub 


安全 性 注意 事项 : 发 送 自己 的 ssh 密 钥 之 前 要 仔细 思考 : 集群 的 其 他 用 户 可 能 有 权 
访问 该 密 钥 。 使 用 您 想 要 共享 Kubernetes 群集 的 所 有 用 户 可 以 访问 的 服务 帐户 ， 
ho KENT EB] ANZ p YA o 


现在 我 们 可 以 创建 一 个 使 用 ssh 3 48517] secret 的 pod， 并 在 一 个 卷 中 使 用 它 


kind: Pod 
apiVersion: vi 


metadata: 
name: secret-test-pod 
labels: 
name: secret-test 
spec: 
volumes: 
- name: secret-volume 
secret: 
secretName: ssh-key-secret 
containers: 


- name: ssh-test-container 
image: mySshImage 
volumeMounts: 
- name: secret-volume 
readOnly: true 
mountPath: "/etc/secret-volume" 


当 容器 中 的 命令 运行 时 ， 密 铀 的 片段 将 可 在 以 下 目录 : 


/etc/secret-volume/ssh-publickey 
/etc/secret-volume/ssh-privatekey 


然后 容器 可 以 自由 使 用 密 钥 数据 建立 一 个 ssh 连接 。 


1& H] RH] : 包含 proditest 凭据 的 pod 


下 面 的 例子 说 明 一 个 pod 消费 一 个 包含 prod 凭据 的 secret * 3 —^* pod 使 用 测试 
环境 凭据 消费 secret 。 


创建 secret : 


$ kubectl create secret generic prod-db-secret --from-literal=us 
ername=produser --from-literal=password=Y4nys7f11 

secret "prod-db-secret" created 

$ kubectl create secret generic test-db-secret --from-literal=us 
ername=testuser --from-literal=password=iluvtests 

secret "test-db-secret" created 


创建 pod : 


apiVersion: v1 

kind: List 

items: 

- kind: Pod 
apiVersion: vi 
metadata: 

name: prod-db-client-pod 

labels: 
name: prod-db-client 

spec: 

volumes: 

- name: secret-volume 
secret: 

secretName: prod-db-secret 
containers: 

- name: db-client-container 
image: myClientImage 
volumeMounts: 

- name: secret-volume 
readOnly: true 
mountPath: "/etc/secret-volume" 
- kind: Pod 
apiVersion: vi 
metadata: 

name: test-db-client-pod 

labels: 
name: test-db-client 

spec: 

volumes: 

- name: secret-volume 
secret: 

secretName: test-db-secret 
containers: 

- name: db-client-container 
image: myClientImage 
volumeMounts: 

- name: secret-volume 
readOnly: true 
mountPath: "/etc/secret-volume" 


这 两 个 容器 将 在 其 文件 系统 上 显示 以 下 文件 ， 其 中 包含 每 个 容器 环境 的 值 : 


/etc/secret-volume/username 
/etc/secret-volume/password 


请 注意 ， 两 个 pod 的 spec 配置 中 仅 有 一 个 字段 有 所 不 同 ; 这 有 助 于 使 用 普通 的 
pod 配置 模板 创建 具有 不 同 功 能 的 pod。 您 可 以 使 用 两 个 service account 进一步 简 
化 基本 pod spec : 一 个 名 为 prod-user 拥有 prod-db-secret ， 另 一 个 称 为 


test-user 拥有 test-db-secret ° Æ > pod spec 可 以 缩短 为 ， 例 如 : 


kind: Pod 
apiVersion: v1 
metadata: 
name: prod-db-client-pod 
labels: 
name: prod-db-client 
spec: 
serviceAccount: prod-db-client 
containers: 
- name: db-client-container 
image: myClientImage 


使 用 案例 : secret 卷 中 以 点 号 开头 的 文件 


为 了 将 数据 “隐藏 "起 来 ( 即 文件 名 以 点 号 开头 的 文件 ) ， 简 单 地 说 让 该 键 以 一 个 点 
开始 。 例 如 ， 当 如 下 secret 被 挂 载 到 卷 中 : 


kind: Secret 
apiVersion: v1 
metadata: 

name: dotfile-secret 

data: 

.secret-file: dmFsdWUtMgOKDQo- 

kind: Pod 
apiVersion: vi 
metadata: 

name: secret-dotfiles-pod 

spec: 

volumes: 

- name: secret-volume 
secret: 

secretName: dotfile-secret 
containers: 

- name: dotfile-test-container 
image: gcr.io/google containers/busybox 
command: 

- ls 
_ Wy 
"/etc/secret-volume" 
volumeMounts: 
- name: secret-volume 
readOnly: true 
mountPath: "/etc/secret-volume" 


Secret-volume 将 包含 一 个 单独 的 文件 ， 叫 做 .secret-file ， dotfile- 
test-container 的 /etc/secret-volume/.secret-file 路 径 下 将 有 该 文件 。 


SEE 
E Se 


以 点 号 开头 的 文件 在 Is -1 的 输出 中 被 隐藏 起 来 了 ; 列 出 目录 内 容 时 ， 必 须 使 用 
Is -1a 才能 查看 它们 。 


使 用 案例 : Secret 仅 对 pod 中 的 一 个 容器 可 见 


考虑 以 下 一 个 需要 处 理 HTTP 请 求 的 程序 ， 执 行 一 些 复 杂 的 业务 逻辑 ， 然 后 使 用 
HMAC 签署 一 些 消 息 。 因 为 它 具 有 复杂 的 应 用 程序 逻辑 ， 所 以 在 服务 器 中 可 能 会 出 
现 一 个 未 被 注意 的 远程 文件 读 取 漏洞 ， 这 可 能 会 将 私 钥 暴露 给 攻击 者 。 


这 可 以 在 两 个 容器 中 分 为 两 个 进程 : 前 端 容 器 ， 用 于 处 理 用 户 交 互 和 业务 逻辑 ， 但 
ee ae D F 并 且 响 应 来 自前 端的 简单 签名 请 
求 (例如 通过 本 地 主机 网 络 ) 。 


-> 


使 用 这 种 分 割 方 法 ， 攻 击 者 现在 必须 欺骗 应 用 程序 服务 器 才能 进行 任意 的 操作 ， 
可 能 比 使 其 读 取 文件 更 难 。 


Jk Sz X, 


端 使 用 secret API 


当 部 署 与 secret API 交互 的 应 用 程序 时 ， 应 使 用 诸如 RBAC 之 类 的 授权 策略 AR 
制 访问 。 


Secret 的 重要 性 通常 不 尽 相 同 ， 其 中 许多 可 能 只 对 Kubernetes 集群 内 (例如 
service account 令 牌 ) 和 对 外 部 P 统 造 成 影响 。 即 使 一 个 应 用 程序 可 以 理解 其 期 望 
的 与 之 交互 的 secret 的 权力 ， 但 是 同一 命名 空间 中 的 其 他 应 用 程序 也 可 以 使 这 些 假 
设 无 效 。 


由 于 这 些 原因 ， 在 命名 空间 中 watch 和 list secret 的 请 求 是 非常 强大 的 功 
能 ， 应 该 避免 这 Bs > AAD WB secret 可 以 让 客户 端 检查 所 有 secret 是 否 在 
该 命名 空间 中 。 在 群集 中 watch 和 list PTA secret 的 能 力 应 该 只 保留 给 最 有 
特权 的 系统 级 组 件 。 


需要 访问 secrets API 的 应 用 程序 应 该 根据 他 们 需要 的 secret 执行 get 请求。 这 
允许 管理 员 限 制 对 所 有 secret 的 访问 ， 同 时 设置 白 名 单 访 问 应 用 程序 需要 的 各 个 
实例 。 


为 了 提高 循环 获取 的 性 能 ， 客 户 端 可 以 设计 引用 secret 的 资源 ， 然 后 watch 资 
源 ， 在 引用 更 改 时 重新 请 求 secret。 此 外 ， 还 提出 了 一 种 ”批量 监控 “AP| 来 让 客户 
端 watch 每 个 资源 ， 该 功能 可 能 会 在 将 来 的 Kubernetes 版 本 中 提供 。 


安全 属性 


保护 


AA secret 对 象 可 以 独立 于 使 用 它们 的 pod 而 创建 ， 所 以 在 创建 、 查 看 和 编 
辑 pod 的 流程 中 secret 被 暴露 的 风险 较 小 。 系 统 还 可 以 对 secret 对 象 采取 额外 
的 预防 措施 ， 例 如 避免 将 其 写 入 到 磁盘 中 可 能 的 位 置 。 


只 有 当 节 点 上 的 pod 需要 用 到 该 secret 时 ， 该 secret 才 会 被 发 送 到 该 节点 上 。 它 
不 会 被 写 入 磁盘 ， 而 是 存储 在 tmpfs 中 。 一 旦 依赖 于 它 的 pod 被 删除 ， 它 就 被 删 


除 。 

在 大 多 数 Kubernetes 项 目 维护 的 发 行 版 中 ， 用 户 与 API server 之 间 的 通信 以 及 从 
API server 到 kubelet 的 通信 都 受到 SSL/TLS 的 保护 。 通 过 这 些 通道 传输 时 ， 
secret 受到 保护 。 


节点 上 的 secret 数据 存储 在 tmpfs 卷 中 ， 因 此 不 会 传 到 节点 上 的 其 他 磁盘 。 


同一 节点 上 的 很 多 个 pod 可 能 拥有 多 个 secret。 但 是 ， 只 有 pod 请 求 的 secret 在 
其 容器 中 才 是 可 见 的 。 因 此 ， 一 个 pod 不 能 访问 另 一 个 Pod 的 secret | 


Pod 中 有 多 个 容器 。 但 是 ，pod 中 的 每 个 容器 必须 请 求 其 挂 载 卷 中 的 secret 卷 才 能 
在 容器 内 可 见 。 这 可 以 用 于 在 Pod 级 别 构建 安全 分 区 。 


风险 


e API server 的 secret 数据 以 纯 文 本 的 方式 存储 在 etcd 中 ; 因此 : 
o 管理 员 应 该 限制 admin 用 户 访问 etcd ; 
o API server 中 的 secret 数据 位 于 etcd 使 用 的 磁盘 上 ; 管理 员 可 能 希望 在 
不 再 使 用 时 擦 除 /粉碎 etcd 使 用 的 磁盘 


e 如 果 您 将 secret 数据 编码 为 base64 的 清单 (JSON 或 YAML) 文件 ， 共 享 该 
文件 或 将 其 检 入 代码 库 ， 这 样 的 话 该 密码 将 会 被 泄露 。 Base64 编码 不 是 一 种 
加 蜜 方式 ， 一 样 也 是 纯 文 本 。 

e 应 用 程序 在 从 卷 中 读 取 secret 后 仍然 需要 保护 secret 的 值 ， 例 如 不 会 意外 记 
录 或 发 送 给 不 信任 方 。 

e 可 以 创建 和 使 用 secret 的 pod 的 用 户 也 可 以 看 到 该 secret 的 值 。 即 使 API 
server 策略 不 允许 用 户 读 取 secret 对 象 ， 用 户 也 可 以 运行 暴露 secret 的 
pod ° 

e 如 果 运 行 了 多 个 副本 ， 那 么 这 些 secret 将 在 它们 之 间 共 享 。 默 认 情 况 下 ，etcd 

不 能 保证 与 SSL/TLS 的 对 等 通信 ， 尽 管 可 以 进行 配置 。 

e 目前 ， 任 何 节点 的 root 用 户 都 可 以 通过 模拟 kubelet 来 读 取 API server 中 的 任 
何 secret。 只 有 向 实际 需要 它们 的 节点 发 送 secret 才能 限制 单个 节点 的 根 漏 洞 
的 影响 ， 该 功能 还 在 计划 中 。 


原文 地 
At : https://github.com/rootsongjc/kubernetes.github.io/blob/master/docs/concepts 
/configuration/secret.md 
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管理 namespace 中 的 资源 配额 


当 用 多 个 团队 或 者 用 户 共 用 同一 个 集群 的 时 候 难免 会 有 资源 竞争 的 情况 发 生 ， 


候 就 需要 对 不 同 团 队 或 用 户 的 资源 使 用 配额 做 出 限制 。 


开启 资源 配额 限制 功能 


目前 有 两 种 资源 分 配 管理 相关 的 控制 策略 插件 ResourceQuota 和 
LimitRange ° 


这 时 


要 启用 它们 只 要 API Server 的 启动 配置 的 KUBE_ADMISSION CONTROL 参数 中 加 


入 了 ResourceQuota 的 设置 ， 这 样 就 给 集群 开启 了 资源 配额 限制 功能 ， 加 入 


LimitRange 可 以 用 来 限制 一 个 资源 申请 的 范围 限制 ， 参 考 为 namesapce 配置 


默认 的 内 存 请 求 与 限额 和 在 namespace 中 配置 默认 的 CPU 请 求 与 限额 。 


两 种 控制 策略 的 作用 范围 都 是 对 于 某 一 namespace’ ResourceQuota 用 来 限制 


namespace 中 所 有 的 Pod 占用 的 总 的 资源 request 和 1limit， 而 LimitRange «= 


用 来 设置 namespace 中 Pod 的 默认 的 资源 request 4 limit 值 。 
资源 配额 分 为 三 种 类 型 : 


e i X 资源 配额 
e 存储 资源 配额 
e 对 象 数量 配额 


关于 资源 配额 的 详细 信息 请 参考 kubernetes 官方 文档 资源 配额 。 


示例 


我 们 为 spark-cluster 这 个 namespace 设置 ResouceQuota 和 
LimitRange ° 


以 下 yaml 文件 可 以 在 kubernetes-handbook 的 manifests/spark-with- 
kubernetes-native-scheduler 目录 下 找到 。 


忆 置 计算 资源 配额 


配置 文件 : spark-compute-resources.yaml 


apiVersion: vi 
kind: ResourceQuota 
metadata: 
name: compute-resources 
namespace: spark-cluster 
spec: 
hard: 
pods: "20" 
requests.cpu: "20" 
requests.memory: 100Gi 
limits.cpu: "40" 
limits.memory: 200Gi 


kubectl -n spark-cluster describe resourcequota compute-resource 
S 


Ae Ep RAS TRI 
配置 文件 : spark-object-counts.yaml 


apiVersion: v1 
kind: ResourceQuota 
metadata: 
name: object-counts 
namespace: spark-cluster 
spec: 
hard: 
configmaps: "10" 
persistentvolumeclaims: "4" 
replicationcontrollers: "20" 
secrets: "10" 
services: "10" 
services.loadbalancers: "2" 


At a CPU Ze A 7t LimitRange 


配置 文件 : spark-limit-range.yaml 


apiVersion: v1 
kind: LimitRange 


metadata: 
name: mem-limit-range 
spec: 
limits: 
- default: 
memory: 50Gi 
cpu: 5 
defaultRequest: 
memory: 1Gi 
cpu: 1 


type: Container 


e default FP limit 的 值 
e defaultRequest FP request 的 值 


A 


e 资源 配额 
e 为 命名 空间 配置 默认 的 内 存 请 求 与 限额 
e 在 命名 空间 中 配置 默认 的 CPU 请 求 与 限额 
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命令 使 用 
Kubernetes 中 的 kubectl 及 其 他 管理 命令 使 用 。 
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docker H P 3t € 2|kubectl¢ 47745 $ 


对 于 没有 使 用 过 kubernetes 的 docker 用 户 ， 如 何 快速 掌握 kubectl 命令 ? 


在 本 文中 ， 我 们 将 向 docker-cli 用 户 介绍 Kubernetes To 如 何 与 api 进行 交互 。 
该 命令 行 工 具 一 一 kubectl， 被 设计 成 docker-cli 用 户 所 熟 RUN 但 是 它们 之 间 


又 存在 一 些 必要 的 差异 。 该 文档 将 向 您 展示 每 个 docker 子 命令 和 kubectl 与 其 等 效 
的 命令 。 


在 使 用 kubernetes 集群 的 时 候 ，docker 命令 通常 情况 是 不 需要 用 到 的 ， 只 有 在 调 
试 程序 或 者 容器 的 时 候 用 到 ， 我 们 基本 上 使 用 kubectl 命令 即 可 ， 所 以 在 操作 
kubernetes 的 时 候 我 们 抛弃 原先 使 用 docker 时 的 一 些 观念 。 

docker run 

如 何 运 行 一 个 nginx Deployment 并 将 其 暴露 出 来 ? 查看 kubectl run 。 


使 用 docker 命令 


$ docker run -d --restart=always -e DOMAIN=cluster --name nginx- 
app -p 80:80 nginx 
a9ec34d9878748d2f33dc20cb25c714f F21da8d40558b45bfaec9955859075d0 


$ docker ps 
CONTAINER ID IMAGE COMMAND C 
REATED STATUS PORTS 
NAMES 
a9ec34d98787 nginx "nginx -g ‘daemon of 2 
seconds ago Up 2 seconds 0.0.0.0:80->80/tcp, 443/t 


cp nginx-app 


使 用 kubectl 命令 


# start the pod running nginx 

$ kubectl run --image-nginx nginx-app --port=80 --env="DOMAIN=cl 
uster" 

deployment "nginx-app" created 


在 大 于 等 于 1.2 版 本 Kubernetes 集群 中 ， 使 用 kubectl run 命令 将 创建 一 个 名 
A "nginx-app" 的 Deployment。 如 果 您 运行 的 是 老 版 本 ， 将 会 创建 一 个 replication 
controller。 如 果 您 想 沿用 上 昌 的 行为 ， 使 用 --generation-zrun/vi 参数 ， 这 样 就 


4-4 @ replication controller e Æ% kubectl run 获取 更 多 详细 信息 


# expose a port through with a service 
$ kubectl expose deployment nginx-app --port=80 --name-nginx-htt 


p 
service "nginx-http" exposed 


在 kubectl 命令 中 ， 我 们 创建 了 一 个 Deployment， 这 将 保证 有 N 个 运行 nginx 的 
pod (N 代表 spec 中 声明 的 replica ž% > RUA 1) 。 我 们 还 创建 了 一 个 service ， 
使 用 selector 匹配 具有 相应 的 selector 的 Deployment。 查 看 快速 开始 获取 更 多 信 
& o 


wo 


默认 情况 下 镜像 会 在 后 台 运 行 ， 与 docker run -d ... 类 似 ， 如 果 您 想 在 前 台 
运行 ， 使 用 : 


kubectl run [-i] [--tty] --attach <name> --image=<image> 


与 docker run ..， 不 同 的 是 ， 如 果 指 定 了 --attach ， 我 们 将 连接 到 
stdin ， stdout 和 stderr ， 而 不 能 控制 具体 连接 到 哪个 输出 流 docker 


END ° 


因为 我 们 使 用 a 启动 了 容器 ， 如 果 您 终止 了 连接 到 的 进程 (例如 ctrl- 
c) ， 容 器 将 会 重启 ， 这 跟 docker run -it FH ° 4B SU 

Deployment (和 它 的 "e ' 您 需要 运行 kubeclt delete deployment 

«name» » 

docker ps 

如 何 列 出 哪些 正在 运行 ? BA kubectl get » 


使 用 docker 命令 


$ docker ps 
CONTAINER ID IMAGE COMMAND C 
REATED STATUS PORTS 
NAMES 
a9ec34d98787 nginx "nginx -g 'daemon of A 


bout an hour ago Up About an hour 0.0.0.0:80->80/tcp, 443/t 
cp nginx-app 


使 用 kubectl 命令 


$ kubectl get po 
NAME READY STATUS RESTARTS AGE 
nginx-app-5jyvm 1/1 Running 0 1h 
docker attach 
如 何 连接 到 已 经 运行 在 容器 中 的 进程 ? 查看 kubectl attach 。 


使 用 docker 命令 : 


$ docker ps 
CONTAINER ID IMAGE COMMAND C 
REATED STATUS PORTS 

NAMES 
a9ec34d98787 nginx "nginx -g ‘daemon of 8 
minutes ago Up 8 minutes 0.0.0.0:80->80/tcp, 443/t 


cp nginx-app 
$ docker attach a9ec34d98787 


使 用 kubectl 命令 


$ kubectl get pods 

NAME READY STATUS RESTARTS AGE 
nginx-app-5jyvm 1/1 Running 0 10m 
$ kubectl attach -it nginx-app-5jyvm 


docker exec 


如 何在 容器 中 执行 命令 ? 查看 kubectl exec » 


使 用 docker 命令 : 


$ docker ps 


CONTAINER ID IMAGE COMMAND C 
REATED STATUS PORTS 

NAMES 
a9ec34d98787 nginx "nginx -g 'daemon of 8 
minutes ago Up 8 minutes 0.0.0.0:80->80/tcp, 443/t 


cp nginx-app 
$ docker exec a9ec34d98787 cat /etc/hostname 
a9ec34d98787 


使 用 kubectl 命令 : 


$ kubectl get po 


NAME READY STATUS RESTARTS AGE 
nginx-app-5jyvm 1/1 Running 0 10m 
$ kubectl exec nginx-app-5jyvm -- cat /etc/hostname 


nginx-app-5jyvm 
执行 交互 式 命令 怎么 办 ? 
使 用 docker 命令 : 


$ docker exec -ti a9ec34d98787 /bin/sh 


7 exit 


使 用 kubectl 命令 : 


$ kubectl exec -ti nginx-app-5jyvm -- /bin/sh 


# exit 
更 多 信息 请 查看 获取 运行 中 容器 的 Shell 环境 。 


docker logs 
如 何 查 看 运行 中 进程 的 stdout/stderr ? 查看 kubectl logs » 


使 用 docker 命令 : 


$ docker logs -f a9e 


192.168.9.1 - - [14/Jul/2015:01:04:02 +0000] "GET / HTTP/1.1" 20 
© 612 "-" "cur1/7.35.0" "." 
192.168.9.1 - - [14/Jul/2015:01:04:03 +0000] "GET / HTTP/1.1" 20 
© 612 "-" "curl/7.35.0" Ww." 


使 用 kubectl 命令 


$ kubectl logs -f nginx-app-zibvs 


10.240.63.110 - - [14/Ju1/2015:01:09:01 +0000] "GET / HTTP/1.1" 
200 612 "-" “curl/7.26.0" "=" 
10.240.63.110 - - [14/Ju1/2015:01:09:02 +0000] "GET / HTTP/1.1" 
200 612 "-" "curl/7.26.0" "=" 


现在 是 时 候 提 一 下 pod 和 容器 之 间 的 细微 差别 了 ; 默认 情况 下 如 果 pod 中 的 进程 

退出 pod 也 不 会 终止 ， 相 反 它 将 会 重启 该 进程 。 这 类 似 于 docker run 时 的 -- 
restart=always 选项 ， 这 是 主要 差别 。 在 docker 中 ， 进 程 的 每 个 调用 的 输出 都 
是 被 连接 起 来 的 ， 但 是 对 于 kubernetes， 每 个 调用 都 是 分 开 的 。 要 查看 以 前 在 
kubernetes 中 执行 的 输出 ， 请 执行 以 下 操作 : 


$ kubectl logs --previous nginx-app-zibvs 


10.240.63.110 - - [14/Ju1/2015:01:09:01 +0000] "GET / HTTP/1.1" 
200 612 "-" "cur1/7.26.0" "-" 
10.240.63.110 - - [14/Ju1/2015:01:09:02 +0000] "GET / HTTP/1.1" 
200 612 "." "curl/7.26.0" "." 


查看 记录 和 监控 集群 活动 获取 更 多 信息 。 


docker stop 和 docker rm 
如 何 停止 和 删除 运行 中 的 进程 ?查看 kubectl delete 。 


使 用 docker 命令 


$ docker ps 


CONTAINER ID IMAGE COMMAND C 
REATED STATUS PORTS 

NAMES 
a9ec34d98787 nginx "nginx -g 'daemon of 2 
2 hours ago Up 22 hours 0.0.0.0:80->80/tcp, 443/t 


cp nginx-app 

$ docker stop a9ec34d98787 
a9ec34d98787 

$ docker rm a9ec34d98787 
a9ec34d98787 


使 用 kubectl 命令 : 


$ kubectl get deployment nginx-app 


NAME DESTRED CURRENT UP-TO-DATE AVAILABLE AGE 
nginx-app 1 1 1 1 2m 

$ kubectl get po -l run=nginx-app 

NAME READY STATUS RESTARTS AGE 
nginx-app-2883164633-aklf7 1/1 Running 0 2m 


$ kubectl delete deployment nginx-app 
deployment "nginx-app" deleted 

$ kubectl get po -l run=nginx-app 

# Return nothing 


请 注意 ， 我 们 不 直接 删除 pod。 使 用 kubectl 命令 ， 我 们 要 删除 拥有 该 pod 的 
Deployment。 如 果 我 们 直接 删除 pod，Deployment 将 会 重新 创建 该 pod。 
docker login 

在 kubectl 中 没有 对 docker login 的 直接 模拟 。 如 果 您 有 兴趣 在 私有 镜像 仓库 
中 使 用 Kubernetes， 请 参阅 使 用 私有 镜像 仓库 。 

docker version 

如 何 查看 客户 端 和 服务 端的 版 本 ? 查看 kubectl version 。 


使 用 docker 命令 : 


$ docker version 

Client version: 1.7.0 

Client API version: 1.19 

Go version (client): go1.4.2 

Git commit (client): Obaf609 

OS/Arch (client): linux/amd64 
Server version: 1.7.0 

Server API version: 1.19 

Go version (server): go1.4.2 

Git commit (server): Obaf609 

OS/Arch (server): linux/amd64 


使 用 kubectl 命令 : 


$ kubectl version 

Client Version: version.Info{Major:"1", Minor:"6", GitVersion:"v 
1.6.9+a3didfa6f4335", GitCommit:"9b77fed11a9843ce3780f 70dd251e92 
901c43072", GitTreeState:"dirty", BuildDate:"2017-08-29T20:32:58 
Z", OpenPaasKubernetesVersion:"vi.03.02", GoVersion:"go1.7.5", C 
ompiler:"gc", Platform:"linux/amd64") 

Server Version: version.Info{Major:"1", Minor:"6", GitVersion:"v 
1.6.9+a3didfa6f4335", GitCommit:"9b77fed11a9843ce3780f70dd251e92 
901c43072", GitTreeState:"dirty", BuildDate:"2017-08-29T20:32:58 
Z", OpenPaasKubernetesVersion:"v1.03.02", GoVersion:"go1.7.5", C 
ompiler:"gc", Platform:"linux/amd64") 


docker info 
如 何 获 取 有 关 环 境 和 配置 的 各 种 信息 ? 查看 kubectl cluster-info ° 


使 用 docker 命令 : 


$ docker info 
Containers: 40 
Images: 168 
Storage Driver: aufs 
Root Dir: /usr/local/google/docker/aufs 
Backing Filesystem: extfs 
Dirs: 248 
Dirpermi1 Supported: false 
Execution Driver: native-0.2 
Logging Driver: json-file 
Kernel Version: 3.13.0-53-generic 
Operating System: Ubuntu 14.04.2 LTS 
CPUs: 12 
Total Memory: 31.32 GiB 
Name: k8s-is-fun.mtv.corp.google.com 
ID: ADUV:GCYR:B3VJ:HMPO:LNPQ:KD5S: YKFQ: 76VN: IANZ: 7TFV: ZBF4: BYJO 
WARNING: No swap limit support 


使 用 kubectl 命令 : 


$ kubectl cluster-info 

Kubernetes master is running at https://108.59.85.141 

KubeDNS is running at https://108.59.85.141/api/vi/namespaces/ku 
be-system/services/kube-dns/proxy 

KubeUI is running at https://108.59.85.141/api/vi/namespaces/kub 
e-system/services/kube-ui/proxy 

Grafana is running at https://108.59.85.141/api/vi/namespaces/ku 
be-system/services/monitoring-grafana/proxy 

Heapster is running at https://108.59.85.141/api/v1/namespaces/k 
ube-system/services/monitoring-heapster/proxy 

InfluxDB is running at https://108.59.85.141/api/vi/namespaces/k 
ube-system/services/monitoring-influxdb/proxy 


原文 地 
址 : https://github.com/rootsongjc/kubernetes.github.io/blob/master/docs/user- 
guide/docker-cli-to-kubectl.md 
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Kubernetes 提 供 的 kubectl 命 令 是 与 集群 交互 最 直接 的 方式 ，v1.6 版 本 的 kubectl 命 令 


参考 图 如 下 








TUE Kubectl C heat Sheet Reference httos:llkubemates io/docsluser-guide/kubactilv1.6! 


podtemplates 








horizontalpodautoscalers(hpa) 
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events(ev) 

poesia (-f FILENAME | TYPE NAME) KEY. 1-VAL. 1 ... KEY. N-VAL. N [--resource-version=version] F serviceaccount I\ N resourcequotas(quota) 

[--overwrite] (-f FILENAME | TYPE NAME) KEY 1-VAL 1 ... KEY N-VAL N [--resource-version-versiop 1、 Settings | configmaps(cm) 

mcd I Commands | Lorton 

y replicationcontrollers(rc) 

completion Basic P to) 

Gommanct: | thirdpartyresources 

—recursive-false. (Beginner) party 














--show-events=true 


—all-namespaces-false >) describe 


H\\ ingresses(ing) 


| limitranges(limits) 





--filenami 
~selectot I\\ namespaces(ns) 
-C, --container=' jobs 








replicasets(rs) 


—interactive-false 
~limit-bytes=0 
paredet 
ince=0s 
—since-tim 
'ail--1 
--timestamps=false 


endpoints(ep) 
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explain 


edit (RESOURCE/NAME | -f FILENAME) [options] - 














Ef FILENAME] | TYPE {(NAME | - label | --all) [options] 


zc, ~container=" Troubleshooting and Debugging Commands 














=p, =pod=" \ o 
-stdin=false 
false [pause 
ILOCAL. PORTJREMOTE PORT [... 
[LOCAL. PORT. N.]REMOTE. PORT. NJ [status | 


[options] 


—accept-hosts- ^localhost$,^127 V0.0 18,^::1 NS" Deploy Commands 


| rolling-update E 

—rollback 
[--resource-version-versior] [--current-replicas=count] --replicas-COUNT 
(f FILENAME | TYPE NAME) [options] 


kubectl 
POSTPUTPATCH' | proxy | (f FILENAME | TYPE NAME | TYPE/NAME) [--min=MINPODS] --max=MAXPODS 
L'spu-percenteCPu] [ags] [options 





| scale 














--reject-method: 
—reject-paths-'^/api/."/pods/.'/exec,^/api/."/pods/.'/attach" 


























-P, --www-prefix-'/static/" 
-c <specific-container> 
«file-spec-src» <file-spec-dest> [options] 


-f FILENAME | TYPE NAME) -p PATCH [options] 


-t FILENAME [options Advanced 
-f FILENAME [options] es 


--all-false apply 
V delete-cluster. 


delete-context 














Cluster Management Commands 








--grace-period--1 
--ignore-daemonsets=false 
--timeout-0s 


NODE NAME KEY. 1-VAL. :TAINT EFFECT 1 ... 
KEY N-VAL.N:TAINT EFFECT N [options] 


--allow-missing-template-key 








-include-extended-apis-true WW 
--no-headers-false. 
-0, —-output-[isonlyami|wide|name|custom- 





\ —certificate-authori 
Set-context —client-certificate-'' 


set-credentials Other Commands chen 


—output-version: Options unset 


Command 
—overwrite-true | -false F 
p get-contexts ==) Global Options 
--prune-whitelist-[] | --log-backtrace-at=:0 


--record=false_/}f —dog:dirz" Options 


w 

-recursive-false = REN 
N log-fiush-frequency-5s. 

seescneme A —logtostderr-true 


-l, -selector-" /J help. --match-server-versioi 
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--stderrthreshold=2 





--validate-true. --token-" 
-~-username=" 
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图 片 - kubectl cheatsheet 


Kubectl 的 子 命令 主要 分 为 8 个 类 另 





e 基础 命令 (初学 者 都 会 使 用 的 ) 


480 


熟悉 这 些 命令 有 助 于 大 家 来 操作 和 管理 Kubernetes 集 群 。 


为 了 使 用 kubectl 命 令 更 加 高 效 ， 我 们 可 以 选择 安 


过 装 一 下 开源 软件 来 增加 操作 kubectl 
命令 的 快捷 方式 ， 同 时 为 kubectl 命 令 增 加 命令 提示 。 


a Ju tools fo supercharga your kubect| ... 













kubectx kubens 


Switch between multiple like Lubectx, but controls 
clusters easily back and Forth the active namespace, 


€ 
ey 










$kubens foo 
$ kubens bar 
$ kubens - 





$ kubectx test —À» use test cluster 









$ kubectx prod —> use'yrod" cluster 
$ kubectx - —> 90 back to “test” 








vive - 


OT 


kube ch - 





kube - ps. 
show active cluster 人 
namespace in bash/zsh prompt: 


(B |minikube:defal) $ Kubecty prod 
(| prod = default) $ 










both Tools support tab completio 
\ and can oe olea looi 









| MEC S WENN 
$ brew install kubectx adds this part 
( gkhub. com folume th/ Lubecty. ) ( thub. c oSco/ Kube-ps ) 


图 片 -增加 kubeclt 命 令 的 工具 (图 片 来 自 网 络 ) 


e kubectx : 用 于 切换 kubernetes context 
e kube-ps1 : 为 命令 行 终端 增加 SPROMPT 字段 
e kube-shell : 交互 式 带 命令 提示 的 kubectl 终 端 


全 部 配置 完成 后 的 kubectl 终 端 如 下 图 所 示 : 


] 1. kube-shell (Python) 

(& 9|kubernetes:dev)^ ~ kube-shell 

kube-shell> kubectl get pod auto-model-master-1509953585131-2025791120-svdrg 

NAME READY STATUS RESTARTS 

auto-model-master- 7909933905 Ie: 2025791120-svdrg 0/1 ImagePullBackOf f 0 

kube-sheLL> kubec t deployment auto-model-master-1509954672638 
auto-model-master-1509950466637 | dev 
auto-model-master-1509953585131 | dev 
auto-model-master-1509954672638 dev 
auto-model-master-1509955973759 | dev 


' kubernetes les 二 ser: admin [F4] In-line help: ON [F10] 





图 片 -增强 的 kubect/ 命 令 


kube-shell 


开源 项 目 Kube-shell 可 以 为 kubectl 提 供 自 动 的 命令 提示 和 补 全 ， 使 用 起 来 特别 方 
便 ， 推 荐 给 大 家 。 


Kube-shell 有 以 下 特性 
e 命令 提示 ， 给 出 命令 的 使 用 说 明 
自动 补 全 ， 列 出 可 选 命令 并 可 以 通过 tab 键 自动 补 人 全， 支持 模 糊 搜 索 
e "o 
e 使 用 tab 键 可 以 列 出 可 选 的 对 象 
vim 模 式 


Mac 下 安装 


pip install kube-shell --user -U 


kube-shell» top node 
NAME CPU(cores) CPU% MEMORY (bytes) MEMORY% 
172.20.0.114 734m 1% 34540Mi 26?6 
172.20.0.115 308m o% 9334Mi 7% 
172.20.0.113 894m 2% 50624Mi 39% 
kube-shell» describe NE 
pe 

job 

storage 

secret 
serviceaccount 
| configmap 
deployment 
deployment 
statefulset 


poddisruptionbudget 
pod 
replicationcontroller 
resourcequota 
persistentvolume 


Cluster: kubernetes Namespace: default User: admin [F4] In-line help: ON [F10] Exit 





图 片 - kube-shell 9t @ 


kubectl 的 身份 认证 
Kubernetes 中 存在 三 种 安全 认证 方式 : 


e CA 证 书 : API server 与 其 它 几 个 组 件 之 间 都 是 通过 这 种 方式 认证 的 

e HTTP base : FP ZAPI server 的 启动 参数 中 指定 的 --token-auth- 
file=/etc/kubernetes/token.csv 文件 中 明文 的 用 户 、 组 、 密 码 和 UID 配 置 

e bearer token : HTTP 请 求 中 header 中 传递 的 Autorization:Bearer 
token ， 这 个 token 通 常 保存 在 创建 角色 跟 serviceaccount 绑 定 的 时 候 生成 
的 secret 中 。 


kubectl 通 过 读 取 kubeconfig 文件 中 的 配置 信息 在 向 API server 发 送 请 求 的 时 候 同 
时 传递 认证 信息 ， 同 时 支持 CA 证 书 和 bearer token 的 认证 方式 ， 请 参考 使 用 
kubeconfig 文 件 配 置 跨 集群 认证 。 


终端 下 kubectl 命 令 自 动 补 全 


建议 使 用 oh-my-zsh， 增 加 对 kubectl 命 令 自动 补 全 支持 。 


修改 ~/,zshrc 文件 ， 增 加 如 下 两 行 : 


plugins-(kubectl) 
source «(kubectl completion zsh) 


保存 后 重启 终端 即 可 生效 。 
参考 : Install and Set Up kubectl 


Copyright © jimmysong.io 2017-2018 all right reserved > powered by 
GitbookUpdated at 2018-05-09 14:15:47 


kubectl 命令 技巧 大 全 


Kubctl 命令 是 操作 kubernetes 集群 的 最 直接 和 最 skillful 的 途径 ， 这 个 60 多 MB 大 
小 的 二 进 制 文件 ， 到 底 有 啥 能 耐 呢 ? 请 看 下 文 : 


Kubectl 自动 补 全 


$ source <(kubectl completion bash) # setup autocomplete in bash 
, bash-completion package should be installed first. 
$ source <(kubectl completion zsh) # setup autocomplete in zsh 


Kubectl 上 下 文 和 配置 


设置 kubectl 命令 交互 的 kubernetes 集群 并 修改 配置 信息 。 参 阅 使 用 
kubeconfig 文件 进行 跨 集群 验证 获取 关于 配置 文件 的 详细 信息 


$ kubectl config view # 显示 合并 后 的 kubeconfig 配置 


# 同时 使 用 多 个 kubeconfig 文件 并 查看 合并 后 的 配置 
$ KUBECONFIG=~/.kube/config:~/. i cigs kubectl config vi 
ew 


# 获取 e2e 用 户 的 密码 
$ kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].u 
ser.passwordj' 


$ kubectl config current-context # 显示 当前 的 上 下 文 
$ kubectl config use-context my-cluster-name # BERDEFS 为 my 
-cluster-name 


# 向 kubeconf 中 增加 支持 基本 认证 的 新 集群 
$ kubectl config set-credentials kubeuser/foo.kubernetes.com --u 
sername=kubeuser --password=kubepassword 


# 使 用 指定 的 用 户 名 和 namespace 设置 上 下 文 
$ kubectl config set-context gce --user=cluster-admin --namespace 
-foo \ 

&& kubectl config use-context gce 


al SSS hl 











创建 对 得 


Kubernetes 的 清单 文件 可 以 使 用 json 或 yaml 格式 定义 。 可 以 以 
.yaml ^ .yml 、 或 者 .json 为 扩展 名 。 


$ kubectl create -f ./my-manifest.yaml 
$ kubectl create -f ./myi.yaml -f ./my2.yaml 
资源 
$ kubectl create -f ./dir 
清单 文件 来 创建 资源 
$ kubectl create -f https://git.io/vPieo 
资源 
$ kubectl run nginx --image-nginx 
实例 
$ kubectl explain pods,svc 
c 的 文档 


# 从 stdin 输入 中 创建 多 个 YAML HR 
$ cat <<EOF | kubectl create -f - 
apiVersion: vi 
kind: Pod 
metadata: 
name: busybox-sleep 
spec: 
containers: 
- name: busybox 
image: busybox 
args: 
- sleep 
"1000000" 
apiVersion: vi 
kind: Pod 
metadata: 
name: busybox-sleep-less 
spec: 
containers: 
- name: busybox 
image: busybox 
args: 
- sleep 
"n 1000 n 
EOF 


# 创建 包含 几 个 key 的 Secret 
$ cat <<EOF | kubectl create -f - 
apiVersion: v1 
kind: Secret 
metadata: 
name: mysecret 
type: Opaque 


data: 
password: $(echo "s33msi4" | base64) 
username: $(echo "jane" | base64) 


EOF 


创建 资源 
使 用 多 个 文件 创建 


使 用 目录 下 的 所 有 
使 用 url 来 创建 
启动 一 个 nginx 


获取 pod 和 sv 


显示 和 查找 资源 


^ A AF SE J Ne 
kubectl4? 44k 24 KA 


# Get commands with basic output 


$ kubectl get services # 列 出 所 有 namesp 
ace 中 的 所 有 service 

$ kubectl get pods --all-namespaces A 列 出 所 有 namesp 
ace 中 的 所 有 pod 

$ kubectl get pods -o wide A 列 出 所 有 pod 并 
显示 详细 信息 

$ kubectl get deployment my-dep # 列 出 指定 deploy 
ment 

$ kubectl get pods --include-uninitialized # 列 出 该 namespac 


e 中 的 所 有 pod 包括 未 初始 化 的 


A 使 用 详细 输出 来 描述 命令 
$ kubectl describe nodes my-node 
$ kubectl describe pods my-pod 


$ kubectl get services --sort-by=.metadata.name # List Services 
Sorted by Name 


# 根据 重启 次 数 排 序列 出 pod 
$ kubectl get pods --sort-by='.status.containerStatuses[0].resta 
rtCount' 


# 获取 所 有 具有 app-cassandra 的 pod 中 的 version 标签 
$ kubectl get pods --selector=app=cassandra rc -o \ 
jsonpath='{.items[*].metadata.labels.version}' 


# 获取 所 有 节点 的 _ ExternalIIP 
$ kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@ 
.type=="ExternalIP")].address}' 


A 列 出 属于 某 个 PC 的 Pod 的 名 字 

# “Jjq “命令 用 于 转换 复杂 的 jsonpath， 参 考 https://stedolan. github. io/j 
q/ 

$ sel=${$(kubectl get rc my-rc --output=json | jq -j '.spec.sele 
ctor | to entries | .[] | "\(.key)=\(.value),"' )%?} 

$ echo $(kubectl get pods --selector-$sel --output=jsonpath={.it 
ems..metadata.name)) 


# 查看 哪些 节点 已 就 绪 

$ JSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.c 
onditions[*]}{@.type}={@.status};{end}{end}' \ 

&& kubectl get nodes -o jsonpath="$JSONPATH" | grep "Ready=True" 


# 列 出 当前 Pod 中 使 用 的 Secret 
$ kubectl get pods -o json | jq '.items[].spec.containers[].env[ 
]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq 


加 = 后 并 
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kubectl rolling-update frontend-vi -f frontend-v2.json 

# 滚动 更 新 pod frontend-vi 

kubectl rolling-update frontend-vi1 frontend-v2 --image-image:v 
A 更 新 资源 名 称 并 更 新 镜像 

kubectl rolling-update frontend --image-image:v2 

4 更 新 frontend pod 中 的 镜像 

kubectl rolling-update frontend-v1 frontend-v2 --rollback 

# 退出 已 存在 的 进行 中 的 滚动 更 新 

cat pod.json | kubectl replace -f - 

# 基于 stdin 输入 的 JSON 替换 pod 


A A AN € A 


B 强制 替换 ， 删 除 后 重新 创建 资源 。 会 导致 服务 中 断 e 
$ kubectl replace --force -f ./pod.json 


A A nginx RC 创建 服务 ， 启 用 本 地 80 端口 连接 到 容器 上 的 9000 端口 
$ kubectl expose rc nginx --port=80 --target-port=8000 


A 更 新 单 容 器 pod 的 镜像 版 本 (tag) 到 v4 
$ kubectl get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/ 
N1:v4/' | kubectl replace -f - 


$ kubectl label pods my-pod new-label-awesome 
# 添加 标签 

$ kubectl annotate pods my-pod icon-url-http://goo.gl/XXBTWq 
# 添加 注解 

$ kubectl autoscale deployment foo --min=2 --max=10 
# 自动 扩展 deployment “foo” 


修补 资源 


使 用 策略 合并 补丁 并 修补 资源 。 


Ae aN ^. li r2 LA 
kubectl?g 4 4x 42 RA 


$ kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":tru 
e))' & 部 分 更 新 节点 


# 更 新 容器 镜像 ; spec.containers[*].name 是 必须 的 ， 因 为 这 是 合并 的 关键 字 
$ kubectl patch pod valid-pod -p '{"spec":{"containers":[{"name" 
:"kubernetes-serve-hostname","image":"new image"}]}}' 


# 使 用 具有 位 置 数组 的 json 补丁 更 新 容器 镜像 
$ kubectl patch pod valid-pod --type='json' -p='[{"op": "replace 
", "path": "/spec/containers/0/image", "value":"new image"}]' 


# 使 用 具有 位 置 数 组 的 json 补丁 禁用 deployment 的 livenessProbe 

$ kubectl patch deployment valid-deployment --type json -p='[ 
{"op": "remove", "path": "/spec/template/spec/containers/0/liven 
essProbe"}]' 


编辑 资源 
在 编辑 器 中 编辑 任何 APL 资源 。 


$ kubectl edit svc/docker-registry Z 编辑 名 
为 docker-registry 的 service 

$ KUBE_EDITOR="nano" kubectl edit svc/docker-registry # 使 用 其 
它 编辑 器 


Scale 资源 


$ kubectl scale --replicas=3 rs/foo 

# Scale a replicaset named 'foo' to 3 
$ kubectl scale --replicas=3 -f foo.yaml 

# Scale a resource specified in "foo.yaml" to 3 
$ kubectl scale --current-replicas-2 --replicas-3 deployment/mys 
gl # If the deployment named mysql's current size is 2, scale m 
ysql to 3 
$ kubectl scale --replicas-5 rc/foo rc/bar rc/baz 

# Scale multiple replication controllers 


删除 资源 


$ kubectl delete -f ./pod.json 

# 删除 pod.json 文件 中 定义 的 类 型 和 名 称 的 pod 
$ kubectl delete pod, service baz foo 

# 删除 名 为 Zbaz7 的 pod 和 名 为 “foo7 的 service 
$ kubectl delete pods,services -1 name=myLabel 

# 删除 具有 name-myLabel 标签 的 pod 和 serivce 
$ kubectl delete pods,services -l name=myLabel --include-uniniti 
alized # 删除 具有 name-myLabel 标签 的 pod 和 service’ &4&m 4 
始 化 的 
$ kubectl -n my-ns delete po,svc --all 

# 删除 my-ns namespace 下 的 所 有 pod 和 serivce， 包 括 尚 未 








初始 化 的 


与 运行 中 的 Pod 交互 


$ kubectl logs my-pod # dump 输出 
pod 的 日 志 (stdout) 

$ kubectl logs my-pod -c my-container # dump 输出 
pod 中 容器 的 日 志 (stdout > pod 中 有 多 个 容器 的 情况 下 使 用 ) 

$ kubectl logs -f my-pod # 流 式 输出 

pod 的 日 志 (stdout) 

$ kubectl logs -f my-pod -c my-container # 流 式 输出 


pod 中 容器 的 日 志 (stdout * pod 中 有 多 个 容器 的 情况 下 使 用 ) 
$ kubectl run -i --tty busybox --image-busybox -- sh # X X sh 
ell 的 方式 运行 pod 


$ kubectl attach my-pod -i # 连接 到 运行 
中 的 容器 

$ kubectl port-forward my-pod 5000:6000 # 转发 pod 
中 的 6000 端口 到 本 地 的 5000 端口 

$ kubectl exec my-pod -- ls / # 在 已 存在 的 
容器 中 执行 命令 (只 有 一 个 容器 的 情况 下 ) 

$ kubectl exec my-pod -c my-container -- ls / # 在 已 存在 的 
容器 中 执行 命令 (pod 中 有 多 个 容器 的 情况 下 ) 

$ kubectl top pod POD NAME --containers # 显示 指定 


pod 和 容器 的 指标 度量 


与 节点 和 集群 交互 


kubectl cordon my-node 

# 标记 my-node 不 可 调度 
kubectl drain my-node 

# 清空 my-node 以 待 维护 
kubectl uncordon my-node 

# 标记 my-node 可 调度 
kubectl top node my-node 

4 显示 my-node 的 指标 度量 
kubectl cluster-info 

4 显示 master 和 服务 的 地 址 
kubectl cluster-info dump 

# 将 当前 集群 状态 输出 到 stdout 


fF uoo Ə A A FF 


$ kubectl cluster-info dump --output-directory=/path/to/cluster - 
state #4 将 当前 集群 状态 输出 到 /path/to/cluster-state 


# 如 果 该 键 和 影响 的 污点 (taint) 已 存在 ， 则 使 用 指定 的 值 替换 
$ kubectl taint nodes foo dedicated-special-user:NoSchedule 


资源 类 型 


下 表 列 出 的 是 kubernetes 中 所 有 支持 的 类 型 和 缩写 的 别名 。 


资源 类 型 
clusters 
componentstatuses 
configmaps 
daemonsets 
deployments 
endpoints 
event 
horizontalpodautoscalers 
ingresses 
jobs 
limitranges 
namespaces 
networkpolicies 
nodes 
statefulsets 
persistentvolumeclaims 
persistentvolumes 
pods 
podsecuritypolicies 
podtemplates 
replicasets 
replicationcontrollers 
resourcequotas 
cronjob 
secrets 
serviceaccount 
services 
storageclasses 


thirdpartyresources 


deploy 


hpa 


ing 


limits 


ns 


no 


pvc 
pv 
po 
psp 


rs 
re 


quota 


sa 


SVC 


格式 化 输出 


要 以 特定 的 格式 向 终端 窗口 输出 详细 信息 ， 可 以 在 kubectl 命令 中 添加 -0 或 
者 -output 标志 。 


输出 格式 描述 
-o=custom-columns=<spec> 使 用 去 号 分 隔 的 自 定 义 列 列表 打印 表格 
-0= tom-col -file= ` > ak 
ctilename- 0 7. 4&E CSAP 66 LPB a Pe RU 
-o=json 输出 JSON 格式 的 API 对 象 
-o-jsonpath-«template» 打印 jsonpath 表达 式 中 定义 的 字段 


joel onp ee 打印 由 文件 中 的 jsonpath 表达 式 定义 的 字段 


<filename> 
-o=name 仅 打印 资源 名 称 
"T 以 纯 文 本 格式 输出 任何 附加 信息 ， 对 于 Pod 
， 包 含 节点 名 称 
-o-yaml 输出 YAML 格式 的 API 对 象 


Kubectl 详细 输出 和 调试 


使 用 -v 或 --v 标志 跟着 一 个 整数 来 指定 日 志 级 别 。 这 里 描述 了 通用 的 
kubernetes 日 志 约 定 和 相关 的 日 志 级 别 。 


X ut 
等 级 描述 
vp ”总 是 对 操作 人 员 可 见 。 
vp o 会 理 的 默认 日 志 级 别 ， 如 果 您 不 需要 详细 输出 。 


-- ”可 能 与 系统 的 重大 变化 相关 的 ， 有 关 稳 定 状态 的 信息 和 重要 的 日 志 信 
V=2 ” 息 。 这 是 对 大 多 数 系统 推荐 的 日 志 级 别 。 


有 关 更 改 的 扩展 信息 。 


V=3 

v=4 ”调试 级 别 详细 输出 。 

vg 显示 请 求 的 资源 。 

-7 ”显示 HTTP 请 求 的 header 。 
vs 显示 HTTP 请 求 的 内 容 。 


e Kubectl 概览 


e JsonPath 手册 


本 文 是 对 官方 文档 的 中 文 翻译 ， 原 文 地 址 : https://kubernetes.io/docs/user- 
guide/kubectl-cheatsheet/ 
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Kubenretes1.6 ¥ 4% Jf] etcd V3 版 本 的 API， 使 用 etcdctl 直接 1s 的 话 只 能 看 
到 /kube-centos 一 个 路 径 。 需 要 在 命令 前 加 上 ETCDCTL_API=3 这 个 环境 变量 
才能 看 到 kuberentes 在 etcd 中 保存 的 数据 。 


ETCDCTL_API=3 etcdctl get /registry/namespaces/default -w=json|p 
ython -m json.tool 


e -w 指定 输出 格式 


将 得 到 这 样 的 json 的 结果 : 


"Count! e; 1, 

"header": { 
"cluster_id": 12091028579527406772, 
"member id": 16557816780141026208, 
"raft term": 36, 
"revision": 29253467 

3 

n kys" : [ 
1 

"create revision": 5, 

"key": "L3J1Z21zdHJ5L25hbWVzcGF j ZXMvZGVmYXVsdA--" , 

"mod revision": 5, 

"value": "azhzAAoPCgJ2MRIJTmFtZXNwYWN1EmIKSAOHZGVmYX 
VsdBIAGgAiACOkZTU2YzMzMDgtMWVhOCOXxMWUS3LTh j ZDCtZ j RLOWQOOWY 4ZWQwMg 
AAAEILCIn4AsscFEKOg9xd6ABIMCgprdWJlcm5ldGVzGggKBkF;jdGl2ZRoAIgA-", 

"version": 1 


j 


使 用 --prefix 可 以 看 到 所 有 的 子 目 录 ， 如 查看 集群 中 的 namespace : 


ETCDCTL_API=3 etcdctl get /registry/namespaces --prefix -w-json| 
python -m json.tool 


输出 结果 中 可 以 看 到 所 有 的 namespace ° 
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"count": 8, 
"header": { 
"cluster_id": 12091028579527406772, 
"member_id": 16557816780141026208, 
"raft_term": 36, 
"revision": 29253722 
3 
"kys: [ 
{ 
"create_revision": 24310883, 
"key": "L3J1Z21zdHJ5L25hbWVzcGF j ZXMvYXVOb21vZGVs" , 
"mod revision": 24310883, 
"value": "azhzAAoPCgJ2MRIJTmFtZXNwYWN1EmQKSgoJYXVOb2 
1vZGVsEgAaACIAKiQ1MjczOTU1ZC1iMzEyLTEXZTctOTcwYy1mNGU5ZDQ5Z jh 1ZD 
AyADgAQgsI7fSWzwUQ6Jv1Z3oAEgwKCmt 1 YmVybmVOZXMaCAoGQWNOaXZ1GgAiAA 


——H 
== Y. 
"version": 1 
ki 
1 


"create revision": 21387676, 

"key": "L3J1Z21zdHJ5L25hbWVzcGF j ZXMvYnJhbmQz" , 

"mod revision": 21387676, 

"value": "azhzAAoPCgJ2MRIJTmFtZXNwYWN1EmEKRwoFYnJhbm 
QSABOAIgAqJGNkZmQ1Y2NmLWEXYZzktMTF1NyO5NZzBj LWYOZTLKND1ImMOGVkKMDIAOA 
BCDAj R9qLOBRDYn83XAXoAEgwKCmt 1 YmVybmVOZXMaCAoGQWNOaXZ1GgAiAA--", 

"version": 1 

tr 
{ 


"create_revision": 5, 

"key": "L3J1Z21zdHJ5L25hbWVzcGF j ZXMvZGVmYXVsdA--" , 

"mod revision": 5, 

"value": "azhzAAoPCgJ2MRIJTmFtZXNwYWNlEmIKSAOoHZGVmYX 
VsdBIAGgAiACOkZTU2YzMzMDgtMWVhOCOXxMWUS3LTh j ZDCtZ j R1OWQOOWY 4ZWQwMg 
AAAEILCIn4AsscFEKOg9xd6ABIMCgprdWJlcm5ldGVzGggKBkF;jdGl2ZRoAIgA-", 

"version": 1 

ty 
{ 


"create_revision": 18504694, 

"key": "L3J1Z21zdHJ5L25hbWVzcGF j ZXMvZGV2" , 

"mod revision": 24310213, 

"value": "azhzAAoPCgJ2MRIJTmFtZXNwYWN1EmwKUgoDZGV2Eg 
AaACIAKiQyOGRlMGVjNSOAZTEZLTEXZTCtOTCwYy1mNGU5ZDQ5Z jh1ZDAyADgAQg 
wI89CezQUQOv2fuQNaCwoEbmFtZRIDZGV2egASDAoKa3ViZXJuZXRlcxoICgZBY3 
RpdmUaACIA", 


ty 
i 


"version": 4 
"Create revision": 10, 
"key": "L3J1Z21zdHJ5L25hbWVzcGF j ZXMva3ViZSiwdWJsaWM-" 


"mod revision": 10, 
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使 用 etcdctl 访 问 kubernetes 数 据 


"value": "azhzAAoPCgJ2MRIJTmFtZXNwYWNlEmcKTQoLa3ViZzS 
1wdWJsaWMSABOAIgAqJGU1ZjhkY211LTFlYTgtMTFlNyO4Y2Q3LWYOZTlIKkNDlmOG 
VkMDIAOABCDAiJ-*LLHBRDdrsDPA3oAEgwKCmt 1YmVybmVOZXMaCAoGQWNOaXZ 1Gg 
AiAAsz", 

"version": 1 

tr 
{ 


"create_revision": 2, 
"key": "L3J1Z21zdHJ5L25hbWVzcGF jZXMva3ViZSi1zeXNOZWO-" 


"mod revision": 2, 

"value": "azhzAAoPCgJ2MRIJTmFtZXNwYWN1EmYKTAOLa3ViZzS 
1ZeXNOZWOSABOAIgAg JGUANMFHMDVKLTFLYTgtMTFINyO4Y2Q3LWYOZTLKND1m0G 
VkMDIAOABCCWwiJ-*LLHBRDoq9ASegASDAoKa3ViZXJuZXRl1cxoICgZBY3RpdmUaAC 
IA", 

"version": 1 

3 
{ 


"Create revision": 3774247, 

"key": "L3J1Z21zdHJ5L25hbWVzcGF j ZXMvc3BhcmstY2x1c3Rl 
cg==", 

"mod_revision": 3774247, 

"value": "azhzAAoPCgJ2MRIJTmFtZXNwYWN1LEOABCmYKDXNWYX 
JrLWNsdXNOZXISABOAIgAqJDMyNj Y3ZDV j LTMOYWMtMTFINy1iZmJkLThhZjF1M2 
E3YZViZDIAOABCDAiA1cbIBRDU3YUAAVoVCgRuYW11lEg1izcGFyay1jbHVzdGVyeg 
ASDAoKa3ViZXJuZXRlcxoICgZBY3RpdmUaACIA", 

"version": 1 

3 
{ 


"create_revision": 15212191, 
"key": "L3J1lZ21zdHJ5L25hbWVzcGF jZXMveWFybi1jbHVzdGVy" 


"mod revision": 15212191, 

"value": "azhzAAoPCgJ2MRIJTmFtZXNwYWN1EnOKYwoMeWFybi 
1jbHVzdGVyEgAaACIAKiQ2YWNhNj k1Y103N2Y5LTEXZTctYmZiZCOAYWYXZTNhN2 
MiYmQyADgAQgsIiqiKzAUQkoqxDloUCgRuYWilEgx5YXJuLWNsdXN0ZXJ6ABIMCg 


prdwJlcm5ldGVzGggKBkF;jdGl2ZRoAIgA-", 
"version": 1 
j 


ll —————————————————————————————X——— E l itj 


key 的 值 是 经 过 base64 编 码 ， 需 要 解码 后 才能 看 到 实际 值 ， 如 : 


$ echo L3J1Z21zdHJ5L25hbWVzcGFjZXMvYXVOb21vZGVs |base64 -d 
/registry/namespaces/automodel 


etcd ? kubernetes 4 Z Zt 4E 
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我 们 使 用 kubectl 命 令 获 取 的 kubernetes 的 对 象 状态 实际 上 是 保存 在 etcd 中 的 ， 使 用 
下 面 的 脚本 可 以 获取 etcd 中 的 所 有 kubernetes 对 象 的 key : 


注意 ， 我 们 使 用 了 ETCD v3 版 本 的 客户 端 命令 来 访问 etcd © 


#!/bin/bash 
# Get kubernetes keys from etcd 
export ETCDCTL_API=3 
keys= etcdctl get /registry --prefix -w json|python -m json.tool| 
grep key|cut -d ":" -f2|tr -d '"'|tr -d ","^ 
for x in $keys;do 
echo $x|base64 -d|sort 
done 


E a X] 


通过 输出 的 结果 我 们 可 以 看 到 kubernetes 的 原 数 据 是 按 何 种 结构 包括 在 kuberentes 
中 的 ， 输 出 结果 如 下 所 示 : 


/registry/ThirdPartyResourceData/istio.io/istioconfigs/default/r 
oute-rule-details-default 
/registry/ThirdPartyResourceData/istio.io/istioconfigs/default/r 
oute-rule-productpage-default 
/registry/ThirdPartyResourceData/istio.io/istioconfigs/default/r 
oute-rule-ratings-default 


/registry/configmaps/default/namerctl-script 
/registry/configmaps/default/namerd-config 
/registry/configmaps/default/nginx-config 


/registry/deployments/default/sdmk - page -sdmk 
/registry/deployments/default/sdmk-payment -web 
/registry/deployments/default/sdmk-report 


我 们 可 以 看 到 所 有 的 Kuberentes 的 所 有 元 数据 都 保存 在 /registry 目录 下 ， 下 一 
层 就 是 API 对 象 类 型 (复数 形式 ) ， 再 下 一 层 是 namespace ， 最 后 一 层 是 对 象 的 
名 字 。 


以 下 是 etcd 中 存储 的 kubernetes 所 有 的 元 数据 类 型 : 


ThirdPartyResourceData 
apiextensions.k8s.io 
apiregistration.k8s.io 
certificatesigningrequests 
clusterrolebindings 
clusterroles 
configmaps 
controllerrevisions 
controllers 

daemonsets 

deployments 

events 
horizontalpodautoscalers 
ingress 

limitranges 

minions 
monitoring.coreos.com 
namespaces 
persistentvolumeclaims 
persistentvolumes 
poddisruptionbudgets 
pods 

ranges 

replicasets 
resourcequotas 
rolebindings 

roles 

secrets 
serviceaccounts 
services 

statefulsets 
storageclasses 
thirdpartyresources 


参考 


e etcd 中 文 文档 
e etcd 官 方 文档 
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集群 安全 性 管理 
Kuberentes 支持 多 租户 ， 这 就 需要 对 集群 的 安全 性 进行 管理 。 
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管理 集群 中 的 TLS 


在 本 书 的 最 佳 实践 部 分 ， 我 们 在 CentOS 上 部 署 了 kuberentes 集 群 ， 其 中 最 开始 又 
重要 的 一 步 就 是 创建 TLS 认 证 的 ， 查 看 创建 TLS 证 书 和 秘 钥 。 很 多 人 在 进行 到 这 一 
步 时 都 会 遇 到 各 种 各 样 千 奇 百 怪 的 问题 ， 这 一 步 是 创建 集群 的 基础 ， 我 们 有 必要 详 
细 了 解 一 下 其 背后 的 流程 和 原理 。 


概览 


每 个 Kubernetes 集 群 都 有 一 个 集群 根 证 书 颁 发 机 构 (CA) 。 集群 中 的 组 件 通常 使 
用 CA 来 验证 API server 的 证 书 ， 由 API 服 务 器 验证 kubelet 客 户 端 证 书 等 。 为 了 支持 
这 一 点 ，CA 证 书包 被 分 发 到 集群 中 的 每 个 节点 ， 并 作为 一 个 sercret 附 加 分 发 到 默 
ikservice account 上 。 或 者 ， 你 的 workload 可 以 使 用 此 CA 建立 信任 。 你 的 应 用 程 
序 可 以 使 用 类 似 于 ACME 草 条 的 协议 ， 使 用 certificates.k8s.io API 请 求证 书 
EZ. 


g 


集群 中 的 TLS 信 任 


让 Pod 中 运行 的 应 用 程序 信任 集群 根 CA 通 常 需 要 一 些 额外 的 应 用 程序 配置 。 您 将 
需要 将 CA 证 书包 添加 到 TLS 客 户 端 或 服务 器 信任 的 CA 证 书 列 表 中 。 例如 ， 您 可 以 
使 用 golang TLS 配 置 通过 解析 证 书 链 并 将 解析 的 证 书 添加 到 tls.Config 结构 中 
的 Certificates 字段 中 ，CA 证 书 捆绑 包 将 使 用 默认 服务 账户 自动 加 载 到 pod 

中 ， 路 径 为 /var/run/secrets/kubernetes.io/serviceaccount/ca.crt ° 如 
果 您 没有 使 用 默认 服务 账户 ， 请 请 求 集群 管理 员 构建 包含 您 有 权 访 问 使 用 的 证 书包 
&) configmap ° 


请 求 认证 
以 下 部 分 演示 如 何 为 通过 DNS 访 问 的 Kubernetes 服 务 创建 TLS 证 书 。 


步骤 0. 下 载 安 装 SSL 


下 载 cfss| 工 具 : https://pkg.cfssl.org/. 


步骤 1. 创建 证 书签 名 请 求 
通过 运行 以 下 命令 生成 私 钥 和 证 书签 名 请 求 〈 或 CSR ) 


$ cat <<EOF | cfssl genkey - | cfssljson -bare server 


{ 
"hosts": [ 
"my-svc.my-namespace.svc.cluster.local", 
"my -pod.my-namespace.pod.cluster.local", 
"172.168.0.24", 
"10.9. 234.2" 


"CN": "my-pod.my-namespace.pod.cluster.local", 
"key" : { 

"algo": "ecdsa", 

"size": 256 


EOF 


172.168.0.24 X service 的 cluster IP > my-svc.my- 
namespace.svc.cluster.local x service 的 DNS 名称， 10.0.34.2 Æ Pod 
4) IP > my-pod.my-namespace.pod.cluster.local 是 pod 的 DNS 名 称 ， 你 可 
以 看 到 以 下 输出 : 


2017/03/21 06:48:17 [INFO] generate received request 
2017/03/21 06:48:17 [INFO] received CSR 
2017/03/21 06:48:17 [INFO] generating key: ecdsa-256 
2017/03/21 06:48:17 [INFO] encoded CSR 


此 命令 生成 两 个 文件 ; 它 生 成 包含 PEM 编 码 的 pkcs 4103 EH RAY server.csr ， 
以 及 包含 仍然 要 创建 的 证 书 的 PEM 编 码 密 钥 的 server-key.pem 。 


步骤 2. 创建 证 书签 名 请 求 对 象 以 发 送 到 Kubernetes 
API 


使 用 以 下 命令 创建 CSR yamlxc fF » 4 RK 8| API server : 


$ cat <<EOF | kubectl create -f - 
apiVersion: certificates.k8s.io/vibeta1 
kind: CertificateSigningRequest 
metadata: 

name: my-svc.my-namespace 
spec: 

groups: 

- system:authenticated 

request: $(cat server.csr | base64 | tr -d '\n') 

usages: 

- digital signature 

- key encipherment 

- server auth 


请 注意 ， 在 步骤 1 中 创建 的 server ,csr 文件 是 base64 编 码 并 存储 
.spec.request 字段 中 。 我们 还 要 求 提供 “数字 签名 ”，“ 密 钥 加 密 " 和 “服务 器 身 
分 验证 " 密 钥 用 途 的 证 书 。 我 们 这 里 支持 列 出 的 所 有 关键 用 途 和 扩展 的 关键 用 途 ， 

hen 可 以 使 用 相同 的 API 请 求 客户 端 证书 和 其 他 证 书 。 


在 API server 中 可 以 看 到 这 些 CSR 处 于 pending 状 态 。 执 行 下 面 的 命令 你 将 可 以 看 
到 : 


$ kubectl describe csr my-svc.my-namespace 


Name: my-svc.my-namespace 
Labels: «none» 
Annotations: <none> 
CreationTimestamp: Tue, 21 Mar 2017 07:03:51 -0700 
Requesting User: yourname@example.com 
Status: Pending 
Subject: 
Common Name: my-svc.my-namespace.svc.cluster.local 


Serial Number: 
Subject Alternative Names: 


DNS Names: my-svc.my-namespace.svc.cluster.local 
IP Addresses: 172.168.0.24 
10.0.34.2 


Events: <none> 


步骤 3. 获取 证 书签 名 请 求 


批准 证 书签 名 请 求 是 通过 自动 批准 过 程 完成 的 ， 或 由 集群 管理 员 一 次 完成 。 有 关 这 
方面 涉及 的 更 多 信息 ， 请 参见 WFR e 


FRA 下 载 签名 并 使 用 
一 旦 CSR 被 签署 并 获得 批准 ， 您 应 该 看 到 以 下 内 容 : 


$ kubectl get csr 


NAME AGE REQUESTOR CONDITIO 
N 

my-svc.my-namespace 10m yourname@example.com Approved 
, Issued 


你 可 以 通过 运行 以 下 命令 下 载 颁发 的 证 书 并 将 其 保存 到 server.crt 文件 中 : 


$ kubectl get csr my-svc.my-namespace -o jsonpath='{.status.cert 
ificate}' ^ 
| base64 -d > server.crt 


现在 你 可 以 用 server.crt 和 server-key.pem 来 做 为 keypair 来 启动 HTTPS 
server ° 


批准 证 书签 名 请 求 


Kubernetes 管理 员 (具有 适当 权限 ) 可 以 使 用 kubectl certificate approve 
和 kubectl certificate deny 命令 手动 批准 (或 拒绝 ) 证 书签 名 请 求 。 但 是 ， 
如 果 您 打算 大 量 使 用 此 APl， 则 可 以 考虑 编写 自动 化 的 证 书 控制 器 。 


如 果 上 述 机 器 或 人 类 使 用 kubectl， 批 准 者 的 作用 是 验证 CSR 满足 如 下 两 个 要 求 : 


1. CSR 的 主体 控制 用 于 签署 CSR 的 私 钥 。 这 解决 了 伪装 成 授权 主体 的 第 三 方 的 
威胁 。 eres ， 此 步骤 将 验证 该 控制 了 用 于 生成 CSR 的 私 钥 。 
2. CSR 的 主体 被 授权 在 请 求 的 上 下 文中 执行 。 这 解决 了 我 们 加 入 群集 的 我 们 不 期 


望 的 主体 的 威胁 。 在 上 述 示例 中 ， 此 步骤 将 是 验证 该 pod 是 否 被 允许 加 入 到 所 
请 求 的 服务 中 。 


当 且 仅 当 满足 这 两 个 要 求 时 ， 审 批 者 应 该 批准 CSR， 否 则 拒绝 CSR。 


给 集群 管理 员 的 一 个 建议 


本 教程 假设 将 signer 设 置 为 服务 证 书 API。Kubernetes controller manageri # J — 
个 signer 的 默认 实现 。 要 启用 它 ， 请 将 --cluster-signing-cert-file 和 -- 
cluster-signing-key-file 参数 传递 给 controller manager， 并 配置 具有 证 书 领 
发 机 构 的 密 钥 对 的 路 径 。 
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Kublet 的 认证 授权 


概览 We 
Kubelet 的 HTTPS 端点 对 外 暴露 了 用 于 访问 不 同 敏感 程度 数据 的 API， 并 允许 您 在 
节点 或 者 容器 内 执行 不 同 权限 级 别 的 操作 。 


本 文档 向 您 描述 如 何 通 过 认证 授权 来 访问 kubelet 的 HTTPS 端点 。 


Kubelet 认证 


默认 情况 下 ， 所 有 未 被 配置 的 其 他 身份 验证 方法 拒绝 的 ， 对 kubelet 的 HTTPS 端 
点 的 请 求 将 被 视 为 匿名 请 求 ， 并 被 授予 system:anonymous 用 户 名 和 


system:unauthenticated 组 。 

如 果 要 禁用 匿名 访问 并 发 送 401 Unauthorized 的 未 经 身份 验证 的 请 求 的 响应 : 
启动 kubelet 时 指定 --anonymous-auth-false 标志 

如 果 要 对 kubelet 的 HTTPS 端点 启用 X509 客户 端 证 书 身份 验证 : 


2 4j kubelet 时 指定 --client-ca-file 标志 ， 提 供 CA bundle 以 验证 客户 
nu P 


e 启动 apiserver 时 指定 --kubelet-client-certificate 和 --kubelet- 


@ 
re wv 


client-key 标志 
e 参阅 apiserver 认证 文档 获取 更 多 详细 信息 。 


启用 API bearer token (包括 service account token) 用 于 向 kubelet 的 HTTPS 3% 
点 进行 身份 验证 : 


e 确保 在 API server 中 开启 了 authentication.k8s.io/vibeta1 API 组 。 
启动 kubelet 时 指定 --authentication-token-webhook > -- 
kubeconfig 和 --require-kubeconfig 标志 

e Kubelet 在 配置 的 API server 上 调用 TokenReview API 以 确定 来 自 bearer 
token 的 用 户 信 息 


Kubelet 授权 

接着 对 任何 成 功 验证 的 请 求 (包括 匿名 请 求 ) 授权 。 黑 认 授 权 模式 为 
AlwaysAllow ， 人 允许 所 有 请 求 。 

细 分 访问 kubelet API 有 很 多 原因 : 


e 启用 匿名 认证 ， 但 匿名 用 户 调用 kubelet API 的 能 力 应 受到 限制 

e 启动 bearer token 认证 ， 但 是 API 用户 (如 service account) 调用 kubelet 
API 的 能 力 应 受到 限制 

e 客户 端 证 书 身份 验证 已 启用 ， 但 只 有 那些 配置 了 CA 签名 的 客户 端 证 书 的 用 户 
才 可 以 使 用 kubelet API 


如 果 要 细 分 访问 kubelet API， 将 授权 委托 给 API server : 


e 确保 API server 中 启用 了 authorization.k8s.io/vibetai API 组 


e 尼 动 kubelet 时 指定 --authorization-mode=webhook ^  --kubeconfig 
fe --require-kubeconfig 标志 

e kubelet 在 配置 的 API server 上 调用 SubjectAccessReview API， 以 确定 每 
个 请 求 是 否 被 授权 


kubelet 使 用 与 apiserver 相同 的 请 求 属 性 方法 来 授权 API 请 求 。 


Verb (动词 ) 是 根据 传 入 的 请 求 的 HTTP 动词 确定 的 : 


HTTP 动词 request 动词 
POST create 
GET HEAD get 
PUT update 
PATCH patch 
DELETE delete 


资源 和 子 资源 根据 传 入 请 求 的 路 径 确定 : 


Kubelet API 资源 子 资源 


/stats/* nodes stats 
/metrics/* nodes metrics 
/logs/* nodes log 
/spec/* nodes spec 
all others nodes proxy 


Namespace 和 API 组 属性 总 是 空 字符 串 ， 资 源 的 名 字 总 是 kubelet 的 Node API 
对 象 的 名 字 。 


当 以 该 模式 运行 时 ， 请 确保 用 户 为 apiserver 指定 了  --kubelet-client- 
certificate 和 --kubelet-client-key 标志 并 授权 了 如 下 属性 : 


e verb=*, resource=nodes, subresource=proxy 
e verb=*, resource=nodes, subresource=stats 

e verb=*, resource=nodes, subresource=log 

e verb=*, resource=nodes, subresource=spec 

e verb=*, resource=nodes, subresource=metrics 
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TLS Bootstrap 


本 文档 介绍 如 何 为 kubelet 设置 TLS 客户 端 证 书 引 导 (bootstrap) ° 

Kubernetes 1.4 引入 了 一 个 用 于 从 集群 级 证 书 颁 发 机 构 (CA) 请 求证 书 的 API。 此 
API 的 原始 目的 是 为 kubelet 提供 TLS 客户 端 证 书 。 可 以 在 这 里 找到 该 提议 ， 在 
feature #43 追踪 该 功能 的 进度 。 


kube-apiserver 配置 


您 必须 提供 一 个 token 文件 ， 该 文件 中 指定 了 至 少 一 个 分 配给 kubelet 特定 
bootstrap 组 的 “bootstrap token” ° 

该 组 将 作为 controller manager 配置 中 的 默认 批准 控制 器 而 用 于 审批 。 随 着 此 功能 
的 成 熟 ， 您 应 该 确保 token 被 绑 定 到 基于 角色 的 访问 控制 (RBAC) 策略 上 ， 该 策 
略 严格 限制 了 与 证 书 配置 相关 的 客户 端 请 求 〈 使 用 bootstrap token) 。 使 用 
RBAC， 将 token 范围 划分 为 组 可 以 带 来 很 大 的 灵活 性 (例如 ， 当 您 配置 完成 节点 
后 ， 您 可 以 禁用 特定 引导 组 的 访问 ) 。 


Token 认证 文件 


Token 可 以 是 任意 的 ， 但 应 该 可 以 表示 为 从 安全 随机 数 生 成 器 (例如 大 多 数 现 代 操 
作 系 统 中 的 /dev/urandom) $ 885 Æ 712841 » AR token 有 很 多 中 方式 。 例 
如 : 


head -c 16 /dev/urandom | od -An -t x | tr -d ' ' 
产生 的 token 类 似 于 这 样 : | 02b50b05283e98ddOfd71db496ef01e8 ° 
Token 文件 应 该 类 似 于 以 下 示例 ， 其 中 前 三 个 值 可 以 是 任何 值 ， 引用 的 组 名 称 应 如 


下 所 示 : 


02b50b05283e98ddofd71db496ef01e8, kubelet -bootstrap, 10001, "System 
: kubelet-bootstrap" 


在 kube-apiserver 命令 中 添加 --token-auth-file-FILENAME 标志 (可 能 在 您 
的 systemd unit 文件 中 ) 来 启用 token 文件 。 


查看 该 文档 获取 更 多 详细 信息 。 


客户 端 证 书 CA E 


在 kube-apiserver 命令 中 添加 --client-ca-file=FILENAME 标志 启用 客户 端 证 
p 
书 认证 ， 指 定 包含 签名 证 书 的 证 书 颁 发 机 构 包 《例如 --client-ca- 


file=/var/lib/kubernetes/ca.pem ) » 


kube-controller-manager 配置 


请 求证 书 的 API 向 Kubernetes controller manager 中 添加 人 证书 颁发 控制 循环 。 使 
用 磁盘 上 的 cissl 本 地 签名 文件 的 形式 。 目 前 ， 所 有 发 型 的 证 书 均 为 一 年 有 效 期 和 
并 具有 一 系列 关键 用 途 。 


签名 文件 


您 必须 提供 证 书 颁发 机 构 ， 这 样 才能 提供 颁发 证 书 所 需 的 密码 资料 。 


kube-apiserver 通过 指定 的 --client-ca-file=FILENAME 标志 来 认证 和 采信 该 
CA ° CA 的 管理 超出 了 本 文档 的 范围 ， 但 建议 您 为 Kubernetes 生成 专用 的 CA » 


假定 证 书 和 密 钥 都 是 PEM 编码 的 。 


Kube-controller-manager 标志 为 : 


--cluster-signing-cert-file="/etc/path/to/kubernetes/ca/ca.crt" 
--cluster-signing-key-file="/etc/path/to/kubernetes/ca/ca.key" 


审批 控制 器 
在 kubernetes 1.7 版 本 中 ， 实 验 性 的 “组 自动 批准 ”控制 器 被 弃 用 ， 新 的 
csrapproving 控制 器 将 作为 kube-controller-manager 的 一 部 分 ， 被 默认 启用 。 


控制 器 使 用 SubjectAccessReview API 来 确定 给 定 用 户 是 否 已 被 授权 允许 请 求 
CSR， 然后 根据 授权 结果 进行 批准 。 为 了 防止 与 其 他 批准 者 冲突 ， 内 置 审批 者 没有 
明确 地 拒绝 CSR， 只 是 忽略 未 经 授权 的 请 求 。 


控制 器 将 CSR 分 为 三 个 子 资源 : 


1. nodeclient :用户 的 客户 端 认证 请 求 O=system:nodes * 
CN=system:node:(node name) ° 

2. selfnodeclient :更 新 具有 相同 0 和 CN 的 客户 端 证 书 的 节点 。 

3. selfnodeserver :更 新 服务 证 书 的 节点 (ALPHA * € € feature gate) ° 


当前 ， 确 定 CSR 是 否 为 selfnodeserver 请 求 的 检查 与 kubelet % 5645 16 4& 3: 
3L (Alpha 功能 ) 相关 联 。 因 此 ， selfnodeserver 的 定义 将 来 可 能 会 改变 ， 并 
且 需 要 Controller Manager 上 的 RotateKubeletServerCertificate feature 
gate。 该 功能 的 进展 可 以 在 kubernetes/feature/#267 上 追踪 。 


- -feature-gates-RotateKubeletServerCertificate-true 


以 下 RBAC ClusterRoles 代表 nodeClient ^ selfnodeclient 和 
selfnodeserver 功能 。 在 以 后 的 版 本 中 可 能 会 自动 创建 类 似 的 角色 。 


# A ClusterRole which instructs the CSR approver to approve a us 
er requesting 
# node client credentials. 
kind: ClusterRole 
apiVersion: rbac.authorization.k8s.io/vibeta1 
metadata: 
name: approve-node-client-csr 
rules: 
- apiGroups: ["certificates.k8s.io"] 
resources: ["certificatesigningrequests/nodeclient"] 
verbs: ["create"] 
# A ClusterRole which instructs the CSR approver to approve a no 
de renewing its 
# own client credentials. 
kind: ClusterRole 
apiVersion: rbac.authorization.k8s.io/vibeta1 
metadata: 
name: approve-node-client-renewal-csr 
rules: 
- apiGroups: ["certificates.k8s.io"] 
resources: ["certificatesigningrequests/selfnodeclient" ] 
verbs: ["create"] 
# A ClusterRole which instructs the CSR approver to approve a no 
de requesting a 
# serving cert matching its client cert. 
kind: ClusterRole 
apiVersion: rbac.authorization.k8s.io/vibeta1 
metadata: 
name: approve-node-server-renewal-csr 
rules: 
- apiGroups: ["certificates.k8s.io"] 
resources: ["certificatesigningrequests/selfnodeserver" | 
verbs: ["create"] 


3x AAT VATE PAETE * d» bootstrap token。 例 如 ， 要 复制 由 已 被 移 除 的 自动 批 
准 标志 提供 的 行为 ， 由 单个 组 批准 所 有 的 CSR : 


# REMOVED: This flag no longer works as of 1.7. 
--insecure-experimental-approve-all-kubelet-csrs-for-group="kube 
let-bootstrap-token" 


管理 员 将 创建 一 个 ClusterRoleBinding 来 定位 该 组 。 


# Approve all CSRs for the group "kubelet-bootstrap-token" 
kind: ClusterRoleBinding 
apiVersion: rbac.authorization.k8s.io/vibeta1 
metadata: 

name: auto-approve-csrs-for-group 
subjects: 
- kind: Group 

name: kubelet-bootstrap-token 

apiGroup: rbac.authorization.k8s.io 
roleRef : 

kind: ClusterRole 

name: approve-node-client-csr 

apiGroup: rbac.authorization.k8s.io 


要 让 节点 更 新 自己 的 凭据 ， 管 理 员 可 以 构造 一 个 ClusterRoleBinding 来 定位 该 
节 点 的 凭据 2 


kind: ClusterRoleBinding 
apiVersion: rbac.authorization.k8s.io/vibeta1 
metadata: 
name: nodei-client-cert-renewal 
subjects: 
- kind: User 
name: system:node:node-1 # Let "node-1" renew its client certi 
ficate. 
apiGroup: rbac.authorization.k8s.io 
roleRef: 
kind: ClusterRole 
name: approve-node-client-renewal-csr 
apiGroup: rbac.authorization.k8s.io 
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群 中 删除 。 


kubelet 配置 


要 向 kube-apiserver 请 求 客 户 端 证 书 ，kubelet 首先 需要 一 个 包含 bootstrap 身份 验 
证 token 的 kubeconfig 文件 路 径 。 您 可 以 使 用 kubectl config set- 

cluster ， set-credentials 和 set-context 来 构建 此 kubeconfig 文件 。 

为 kubectl config set-credentials 提供 kubelet-bootstrap 的 名 称 ， 并 
包含 --token = «token-value» ， 如 下 所 示 : 


kubectl config set-credentials kubelet-bootstrap --token=${BOOTS 
TRAP_TOKEN} --kubeconfig=bootstrap.kubeconfig 


启动 kubelet 时 ， 如 果 --kubeconfig 指定 的 文件 不 存在 ， 则 使 用 bootstrap 
kubeconfig 向 API server 请 求 客户 端 证 书 。 在 批准 kubelet 的 证 书 请 求 和 回执 
时 ， 将 包含 了 生成 的 密 钥 和 证 书 的 kubeconfig 文件 写 入 由 -kubeconfig 指定 的 
路 径 。 证 书 和 密 钥 文件 将 被 放置 在 由 --cert-dir 指定 的 目录 中 。 


启动 kubelet 时 启用 bootstrap 用 到 的 标志 : 


--experimental-bootstrap-kubeconfig="/path/to/bootstrap/kubeconf 
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此 外 ， 在 1.7 中 ，kubelet 实现 了 Alpha 功能 ， 使 其 客户 端 和 /或 服务 器 都 能 轮转 提 
供 证 书 。 


可 以 分 别 通过 kubelet 中 的 RotateKubeletClientCertificate 和 
RotateKubeletServerCertificate 功能 标志 启用 此 功能 ， 但 在 未 来 版 本 中 可 能 
会 以 向 后 兼容 的 方式 发 生变 化 。 


--feature-gates=RotateKubeletClientCertificate=true, RotateKubele 
tServerCertificate=true 


RotateKubeletClientCertificate 可 以 让 kubelet 在 其 现 有 凭据 到 期 时 通过 创 
建新 的 CSR 来 轮换 其 客户 端 证 书 。 RotateKubeletServerCertificate 可 以 让 
kubelet 在 其 引导 客户 端 凭据 后 还 可 以 请 求 服务 证 书 ， 并 轮换 该 证 书 。 服 务 证 书目 
前 不 要 求 DNS X IP SANs ° 


kubectl 审批 


签名 控制 器 不 会 立即 签署 所 有 证 书 请 求 。 相 反 ， 它 会 一 直 等 待 直到 适当 特权 的 用 户 
被 标记 为 “已 批准 " 状态 。 这 最 终 将 是 由 外 部 审批 控制 器 来 处 理 的 自动 化 过 程 ， 但 是 
对 于 alpha 版 本 的 API 来 说 ， 可 以 由 集群 管理 员 通 过 kubectl 命令 手动 完成 。 
管理 员 可 以 使 用 kubectl get csr 命令 列 出 所 有 的 CSR， 使 用 kubectl 


describe csr «name» 命令 描述 某 个 CSR 的 详细 信息 。 在 1.6 版 本 以 前 ， 没 有 直 
接 的 批准 /拒绝 命令 ， 因 此 审批 者 需要 直接 更 新 Status 信息 (查看 如 何 实现 ) 。 此 


后 的 Kubernetes 版 本 中 提供 了 kubectl certificate approve «name» 和 


kubectl certificate deny <name> 命令 。 
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创建 用 户 认证 授权 的 kubeconfig 文 件 


当 我 们 安装 好 集群 后 ， 如 果 想 要 把 kubect| 命 用 户 使 用 ， 就 不 得 不 对 用 户 的 
身份 进行 认证 和 对 其 权限 做 出 限制 。 


下 面 以 创建 一 个 devuser 用 户 并 将 其 绑 定 到 dev 和 test A^ namespace 为 例 说 
Bj o 


创建 CA te P fe bt 4] 


创建 devuser-csr.json 文件 


{ 
"CN": "devuser", 
"hosts": [], 
"key": { 
"algo": "rsa", 
"size": 2048 
}, 
"names": [ 
{ 
no was "CN", 
"ST": "BeiJing", 
My Ws "BeiJing", 
WO "k8s", 
NOU": "System" 
} 
] 
} 


生成 CA 证书 和 私 铀 


在 创建 TLS 证 书 和 秘 钥 一 节 中 我 们 将 生成 的 证 书 和 秘 钥 放 在 了 所 有 节点 的 
/etc/kubernetes/ssl 目录 下 ， 下 面 我 们 再 在 master 节点 上 为 devuser 创建 证 
书 和 秘 铀 ， 在 /etc/kubernetes/ssl 目录 下 执行 以 下 命令 


执行 该 命令 前 请 先 确保 该 目录 下 已 经 包含 如 下 文件 : 


ca-key.pem ca.pem ca-config.json devuser-csr.json 


$ cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config. 
json -profile=kubernetes devuser-csr.json | cfssljson -bare devu 


ser 

2017/08/31 13:31:54 
2017/08/31 13:31:54 
2017/08/31 13:31:54 
2017/08/31 13:31:55 
2017/08/31 13:31:55 


[INFO] 
[INFO] 
[INFO] 
[INFO] 
[INFO] 


generate received request 

received CSR 

generating key: rsa-2048 

encoded CSR 

signed certificate with serial number 


43372632012323103879829229080989286813242051309 
2017/08/31 13:31:55 [WARNING] This certificate lacks a "hosts" f 
ield. This makes it unsuitable for 
websites. For more information see the Baseline Requirements for 
the Issuance and Management 
of Publicly-Trusted Certificates, v.1.1.6, from the CA/Browser F 
orum (https://cabforum.org); 
specifically, section 10.2.3 ("Information Requirements"). 


这 将 生成 如 下 文件 : 


devuser.csr devuser-key.pem devuser.pem 


创建 kubeconfig 文件 


Z LH ie 群 A. BT 

export KUBE_APISERVER="https://172.20.0.113:6443" 
kubectl config set-cluster kubernetes \ 
--certificate-authority=/etc/kubernetes/ssl/ca.pem \ 
--embed-certs=true \ 

--server=${KUBE_APISERVER} \ 

- -kubeconfig=devuser .kubeconfig 

kubectl config set-credentials devuser \ 
--client-certificate=/etc/kubernetes/ssl/devuser.pem \ 
- -client-key-/etc/kubernetes/ssl/devuser-key.pem \ 
--embed-certs=true \ 

- -kubeconfig=devuser .kubeconfig 

ta ET 

kubectl config set-context kubernetes \ 
--cluster=kubernetes \ 

--user=devuser \ 

--namespace=dev \ 

- -kubeconfig=devuser .kubeconfig 


Hf 
H 


A HK BALEFS 
kübecti config use-context kubernetes --kubeconfig-devuser.kubec 
onfig 


我 们 现在 查看 kubectl 的 context : 


kubectl config get-contexts 


CURRENT NAME CLUSTER AUTHINFO NA 
MESPACE 
* kubernetes kubernetes admin 


default-context default-cluster default-admin 


显示 的 用 户 仍然 是 admin， 这 是 因为 ipiis 使 用 了 $HOME/.kube/config 文件 
作为 了 默认 的 context 配置 ， 我 们 只 需要 将 其 用 刚 生成 的 ”devuser .kubeconfig 
文件 替换 即 可 。 


cp -f ./devuser.kubeconfig /root/.kube/config 


关于 kubeconfig 文件 的 更 多 信息 请 参考 使 用 kubeconfig 文件 配置 跨 集群 认证 。 


RoleBinding 


如 果 我 们 想 限 制 devuser 用 户 的 行为 ， 需 要 使 用 RBAC 创 建 角 色 绑 定 以 将 该 用 户 的 
行为 限制 在 茶 个 或 茶几 个 namespace 空间 范围 内 ， 例 如 : 


kubectl create rolebinding devuser-admin-binding --clusterrole=a 
dmin --user=devuser --namespace=dev 
kubectl create rolebinding devuser-admin-binding --clusterrole=a 
dmin --user=devuser --namespace=test 


3X ## devuser 用 户 对 dev 和 test 两 个 namespace 具有 完全 访问 权限 。 


让 我 们 来 验证 以 下 ， 现 在 我 们 在 执行 : 


A 获取 当前 的 context 

kubectl config get-contexts 

CURRENT NAME CLUSTER AUTHINFO NAMESPACE 
* kubernetes kubernetes devuser dev 

" kubernetes kubernetes devuser test 

A 无 法 访问 default namespace 


kubectl get pods --namespace default 

Error from server (Forbidden): User "devuser" cannot list pods in 
the namespace "default". (get pods) 

# 默认 访问 的 是 dev namespace， 您 也 可 以 重新 设置 context 让 其 默认 访问 tes 
t namespace 

kubectl get pods 

No resources found. 


Hu ————————————— ]má(M ri 


现在 kubectl 命令 默认 使 用 的 context 就 是 devuser 了 ， 且 该 用 户 只 能 操作 dev 和 
test 这 两 个 namespace， 并 拥有 完全 的 访问 权限 。 


可 以 使 用 我 写 的 create-usersh 脚 本 来 创建 namespace 和 用 户 并 授权 ， 参 考 说 明 e 
关于 角色 绑 定 的 更 多 信息 请 参考 RBAC 一 一 基于 角色 的 访问 控制 。 


Copyright © jimmysong.io 2017-2018 all right reserved * powered by 
GitbookUpdated at 2018-05-09 14:15:47 


IP 伪装 代理 


本 文 将 讲述 如 何 配 置 和 启用 ip-masq-agent。 


创建 ip-masq-agent 
要 创建 ip-masq-agent， 运 行 下 面 的 kubectl 命令 


kubectl create -f https://raw.githubusercontent.com/kubernetes-i 
ncubator/ip-masq-agent/master/ip-masq-agent.yaml 


关于 ip-masq-agent 的 更 多 信息 请 参考 该 文档 。 


在 大 多 数 情况 下 ， 默 认 的 一 套 规 则 应 该 是 足够 的 ; 但 是 ， 如 果 内 置 的 规则 不 适用 于 
您 的 集群 ， 您 可 以 创建 并 应 用 ConfigMap 来 自 定 义 受 影响 的 IP 范围 。 例 如 ， 为 了 
仅 允许 ip-masq-agent 考虑 10.0.0.0/8， 您 可 以 在 名 为 “config” 的 文件 中 创建 以 下 
ConfigMap ° 


nonMasqueradeCIDRs: 
- 10.0.0.0/8 
resyncInterval: 60s 


注意 : 重要 的 是 ， 该 文件 被 命名 为 config， 因 为 默认 情况 下 ， 该 文件 将 被 用 作 ip- 
masq-agent 查找 的 关键 字 。 


运行 下 列 命令 将 ConfigMap 添加 到 您 的 集群 中 : 


kubectl create configmap ip-masq-agent --from-file=config --name 
space=kube-system 


这 将 会 更 新 /etc/config/ip-masg-agent 文件 ， 并 每 隔 resyscinterval 时 间 段 检查 
遍 该 文件 ， 将 配置 应 用 到 集群 的 节点 中 。 


iptables -t nat -L IP-MASQ-AGENT 

Chain IP-MASQ-AGENT (1 references) 

target prot opt source destination 

RETURN all -- anywhere 169.254.0.0/16 /* 
ip-masq-agent: cluster-local traffic should not be subject to M 

ASQUERADE */ ADDRTYPE match dst-type !LOCAL 


RETURN all -- anywhere 10.0.0.0/8 £^ 
ip-masq-agent: cluster-local 
MASQUERADE all -- anywhere anywhere / 


* ip-masq-agent: outbound traffic should be subject to MASQUERAD 
E (this match must come after cluster-local CIDR matches) */ ADD 
RTYPE match dst-type !LOCAL 


默认 情况 下 ， 本 地 链 路 范围 (169.254.0.0/16) 也 由 ip-masq 代理 处 理 ， 该 代理 设 
置 相应 的 iptables 规则 。 想 要 让 ip-masq-agent 忽略 本 地 链 路 ， 您 可 以 在 
ConfigMap 中 将 masqLinkLocal 7% Z 7j true ° 


nonMasqueradeCIDRs: 
- 10.0.0.0/8 

resyncInterval: 60s 

masqLinkLocal: true 


IP 伪装 代理 用 户 指南 


ip-masq- can i A 配置 iptables 规则 将 Pod 的 IP 地 址 隐藏 在 集群 node 节点 的 
IP 地 址 后 面 。 这 通常 在 将 流量 发 送 到 群集 的 pod CIDR 范围 之 外 的 目的 地 时 执行 。 


关键 术语 
e NAT (网 络 地 址 转换 ) 


是 一 种 通过 修改 IP 头 中 的 源 和 /或 目标 地 址 信息 来 将 一 个 IP 地 址 重 映射 到 另 一 
个 IP 地 址 的 方法 。 通 常 由 执行 |P 路 由 的 设备 完成 。 


e Masquerading (45 €) 


NAT 的 一 种 形式 ， 通 常用 于 执行 多 个 地 址 转换 ， 其 中 多 个 源 IP RUM USUS 
单个 地 址 之 后 ， 通 常 是 由 某 设 备 进行 |P Bw o £ kubernetes 中 ， 这 是 Node 
的 |P 地 址 。 


e CIDR (无 类 域内 路 由 选择 ) 


基于 可 变 长 度 子 网 掩 码 ， 人 允许 指定 任意 长 度 的 前 级 。CIDR 引入 了 一 种 新 的 IP 
地 址 表示 方法 ， 现 在 通常 被 称 为 CIDR 表示 法 ， 将 地 址 或 路 由 前 缓 的 比特 位 数 
作为 后 级 ， 例 如 192.168.2.0/24。 


e 本 地 链 路 


本 地 链 路 地 址 是 仅 能 在 主机 连接 的 网 段 或 广播 域内 进行 有 效 通 信 的 网 络 地 址 。 
IPv4 的 链 路 本 地 地 址 在 CIDR 表示 法 定义 的 地 址 块 是 169.254.0.0/16 ° 


Ip-masq-agent 在 将 流量 发 送 到 集群 node 节点 的 IP 和 ClusterIP 范围 之 外 的 目的 
地 时 ， 会 配置 iptables 规则 来 处 理 伪 装 的 node/pod IP 地 址 。 这 基本 上 将 pod 的 IP 
地 址 隐藏 在 了 集群 node 节点 的 IP 地址 后 面 。 在 某 些 环境 中 ， 到 “外 部 ”地 址 的 流 
量 必 须 来 自己 知 的 机 器 地 址 。 例 如 ， 在 Google Cloud 中 ， 到 互联 网 的 任何 流量 必 

须 来 自 庶 拟 机 的 |P。 当 使 用 容器 时 ， 如 在 GKE 中 ，Pod IP TURCIS ^ a nó 
了 避免 这 种 情况 ， 我 们 必须 将 Pod IP 隐藏 在 
为 “伪装 ”。 黑 认 情 况 下 ， 配 置 代理 将 RFC 1918 指 定 的 三 个 专用 IP à ae id 
CIDR ° J&B &,4& 10.0.0.0/8 ` 172.16.0.0/12 和 192.168.0.0/16 » RUAT > 4X 
理 还 将 本 地 链 路 (169.254.0.0/16) WA FEAR CIDR。 代 理 配 置 为 每 隔 60 秒 从 
/etc/config/ip-masq-agent 位 置 重新 加 载 其 配置 ， 这 也 是 可 配置 的 。 
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Pod CIDR: — 10.1.1.0/24 












Traffic Masqueraded behind eth0 
(external to cluster) 
Src: 10.128.1.2 















Traffic Not Masqueraded Dst: 35.188 24.176 
(local to cluster) DE 
Src: 10.1.1.2 M 
Dst: 10.1.3.1 D 
GON Z 
(10.128.1.2) 
Sre: 10.1.1.4 
Src: 10.1.1.2 Dst: 35.188.24.176 
Dst: 10.1.3.1 cbr0 
(10.1.1.1/24) 
Node 





10.1.1.1.2/24 10.1.1.1.3/24 10.1.1.1.3/24 10.1.1.1.4/24 





~ 





Ah - /P 伪 装 代 理 示意 图 


代理 的 配置 文件 必须 使 用 yaml 或 json 语法 ， 并 且 和 包含 以 下 三 个 可 选 的 key: 


e nonMasqueradeCIDRs : 使 用 CIDR 表示 法 指定 的 非 伪装 范围 的 字符 串 列 
Ja 

e masqLinkLocal : —^ 7/5 4H (true/false) ， 表 示 是 否 将 流量 伪装 成 本 地 链 路 
前 级 169.254.0.0/16。 默 认为 false ° 

e resynclnterval : 代理 尝试 从 磁盘 重新 加 载 配置 的 时 间 间 隔 。 例 如 '30s' 其 中 
s' 是 秒 ，'ms' EST... 


到 10.0.0.0/8 ` 172.16.0.0/12 和 192.168.0.0/16 范围 的 流量 将 不 会 被 伪装 。 任 何其 
他 流量 (假定 是 互联 网 ) 将 被 伪装 。 这 里 有 个 例子 ， 来 自 pod 的 本 地 目的 地 址 可 以 
是 其 节点 的 IP 地 址 、 其 他 节点 的 地 址 或 Cluster IP 范围 中 的 一 个 IP 地 址 。 其 他 任 
何 流量 都 将 默认 伪装 。 以 下 条 目 显示 ip-masq-agent 应 用 的 默认 规则 集 : 


iptables -t nat -L IP-MASQ-AGENT 

RETURN all -- anywhere 169.254.0.0/16 /* 
ip-masq-agent: cluster-local traffic should not be subject to M 

ASQUERADE */ ADDRTYPE match dst-type !LOCAL 

RETURN all -- anywhere 10.0.0.0/8 y 
ip-masq-agent: cluster-local traffic should not be subject to M 

ASQUERADE */ ADDRTYPE match dst-type !LOCAL 

RETURN all -- anywhere 172.16.0.0/12 /* 
ip-masq-agent: cluster-local traffic should not be subject to M 

ASQUERADE */ ADDRTYPE match dst-type !LOCAL 

RETURN all -- anywhere 192.168.0.0/16 /* 
ip-masq-agent: cluster-local traffic should not be subject to M 

ASQUERADE */ ADDRTYPE match dst-type !LOCAL 

MASQUERADE all -- anywhere anywhere / 
* ip-masq-agent: outbound traffic should be subject to MASQUERAD 
E (this match must come after cluster-local CIDR matches) */ ADD 
RTYPE match dst-type !LOCAL 


默认 情况 下 ， 在 GCE/GKE 中 将 启动 kubernetes 1.7.0 版 本 ，ip-masq-agent 已 经 
在 集群 中 运行 。 如 果 您 在 其 他 环境 中 运行 kubernetes， 那 么 您 可 以 将 ip-masq- 
agent 以 DaemonSet 的 方式 在 集群 中 运行 。 


原文 地 址 : https://k8smeetup.github.io/docs/tasks/administer-cluster/ip-masq- 
agent/ 


译 者 : rootsongjc 
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使 用 kubeconfig 或 token 进行 用 户 身 份 认证 


在 开启 了 TLS 的 集群 中 ， 每 当 与 集群 交互 的 时 候 少 不 了 的 是 身份 认证 ， 使 用 
kubeconfig ( 即 证 书 ) 和 token 两 种 认证 方式 是 最 简单 也 最 通用 的 认证 方式 ， 在 
dashboard 的 登录 功能 就 可 以 使 用 这 两 种 登录 功能 。 


下 文 分 两 块 以 示例 的 方式 来 讲解 两 种 登陆 认证 方式 : 


e A brand 命名 空间 下 的 brand 用 户 创建 kubeconfig 文件 
e 为 集群 的 管理 员 (拥有 所 有 命名 空间 的 amdin 权限 ) 创建 token 


使 用 kubeconfig 


如 何 生成 kubeconfig 文件 请 参考 创建 用 户 认证 授权 的 kubeconfig 文 件 。 
注意 我 们 生成 的 kubeconfig 文件 中 没有 token 字段 ， 需 要 手动 添加 该 字段 。 


比如 我 们 为 brand namespace 下 的 brand 用 户 生成 了 名 为 brand.kubeconfig 
的 kubeconfig 文件 ， 还 要 再 该 文件 中 追加 一 行 token 的 配置 (如 何 生成 token 
将 在 下 文 介绍 ) ， 如 下 所 示 : 


! brand.kubeconfig X 


apiVersion: v1 

clusters: 

- cluster: 
certificate-authority-data: LSOtLS1CRUdJTiBDRVJUSUZJQOFURSOtLSOtCK1JSURtakN 
server: https://172.20.0.113:6443 

name: kubernetes 

contexts: 

— context: 
cluster: kubernetes 
namespace: brand 
user: brand 

name: kubernetes 

13 current-context: "kubernetes" 

14 kind: Config 

15 preferences: {} 

16 users: 





oan oa uU i» wn 请 


PrP PR 
NF © 


17 - name: brand 

18 usen: 

19 client-certificate-data: LSO0tLS1CRUdJTiBDRVJUSUZJQOFURSOtLSOtCK1JSUQwakNDQX 
20 client-key-data: LSOtLS1CRUdJTiBSUOEgUFJJVKkFURSBLRVKtLSOtLQpNSULTFb3dJQkFBSO 
21 token: a09bb459d67d876cf1829b4047394a5a 


图 片 - kubeconfig X4 


对 于 访问 dashboard 时 候 的 使 用 kubeconfig 文件 如 brand.kubeconfig 必须 追 
到 token 字段 ， 否 则 认证 不 会 通过 。 而 使 用 kubectl 命令 时 的 用 的 kubeconfig 
文件 则 不 需要 包含 token 字段 。 


生成 token 


需要 创建 一 个 admin 用 户 并 授予 admin 角 色 绑 定 ， 使 用 下 面 的 yaml 文 件 创 建 admin 用 
户 并 赋予 他 管理 员 权 限 ， 然 后 可 以 通过 token 访 问 kubernetes， 该 文件 见 admin- 
role.yaml ° 


+ mkubernetes $ 4 x sj 4x Radmin A P “token 


kind: ClusterRoleBinding 
apiVersion: rbac.authorization.k8s.io/vibeta1 
metadata: 

name: admin 

annotations: 


rbac.authorization.kubernetes.io/autoupdate: 


roleRef: 
kind: ClusterRole 
name: cluster-admin 
apiGroup: rbac.authorization.k8s.io 
subjects: 
- kind: ServiceAccount 
name: admin 
namespace: kube-system 
apiVersion: v1 
kind: ServiceAccount 
metadata: 
name: admin 
namespace: kube-system 
labels: 
kubernetes.io/cluster-service: "true" 
addonmanager.kubernetes.io/mode: Reconcile 


然后 执行 下 面 的 命令 创建 serviceaccount fe A BA > 


kubectl create -f admin-role.yaml 


创建 完成 后 获取 secret 中 token 的 值 。 


"true" 


# %Radmin-token secret 4% F 
$ kubectl -n kube-system get secret|grep admin-token 


admin-token-nwphb kubernetes.io/service 
-account-token 3 6m 

# 获取 token 的 值 

$ kubectl -n kube-system describe secret admin-token-nwphb 

Name: admin-token-nwphb 

Namespace: kube-system 

Labels: <none> 

Annotations: kubernetes.io/service-account.name-admin 


kubernetes.io/service-account.uid=f37bd044-bfb3-11e7-87c 
0o -fAe9d49f8edO 


Type: kubernetes.io/service-account-token 
Data 

namespace: 11 bytes 

token: 非常 长 的 字符 串 

ca.crt: 1310 bytes 


也 可 以 使 用 jsonpath 的 方式 直接 获取 token 的 值 ， 如 : 


kubectl -n kube-system get secret admin-token-nwphb -o jsonpath={ 
.data.token}|base64 -d 


[| 


注意 : yaml 输出 里 的 那个 token 值 是 进行 base64 编码 后 的 结果 ， 一 定 要 将 
kubectl 的 输出 中 的 token 值 进行 base64 解码 ， 在 线 解码 工具 base64decode ， 
Linux 和 Mac 有 自 带 的 base64 命令 也 可 以 直接 使 用 ， 输 入 base64 是 进行 纺 
码 ，Linux 中 base64 -d 表示 解码 ，Mac 中 使 用 base64 -D 。 


我 们 使 用 了 base64 对 其 重新 解码 ， 因 为 secret 都 是 经 过 base64 编码 的 ， 如 果 直 
接 使 用 kubectl 中 查看 到 的 token 值 会 认证 失败 ， 详 见 secret 配置 。 关 于 
JSONPath 的 使 用 请 参考 JSONPath 手册 。 


更 简单 的 方式 是 直接 使 用 kubectl describe 命令 获取 token 的 内 容 (经 过 base64 
解码 之 后 ) 


kubectl describe secret admin-token-nwphb 


为 普通 用 户 生 成 token 


为 指定 namespace 分 配 该 namespace 的 最 高 权限 ， 这 通常 是 在 为 某 个 用 户 〈 组 织 或 
者 个 人 ) 划分 了 namespace 之 后 ， 需 要 给 该 用 户 创建 token 登 陆 kubernetes 
dashboard 或 者 调用 kubernetes API 的 时 候 使 用 。 


每 次 创建 了 新 的 namespace 下 都 会 生成 一 个 默认 的 token， 名 为 default-token- 
xxxx ° default 就 相当 于 该 namespace 下 的 一 个 用 户 ， 可 以 使 用 下 面 的 命令 给 
该 用 户 分 配 该 namespace 的 管理 员 权 限 。 


kubectl create rolebinding $ROLEBINDING_NAME --clusterrole-admin 
--serviceaccount=$NAMESPACE: default --namespace-$NAMESPACE 


e $ROLEBINDING_NAME 必须 是 该 namespace 下 的 唯一 的 

e admin 表示 用 户 该 namespace 的 管理 员 权限 ， 关 于 使 用 clusterrole 进行 
更 细 粒 度 的 权限 控制 请 参考 RBAC 一 一 基于 角色 的 访问 控制 。 

e 我 们 给 默认 的 serviceaccount default 分 配 admin 权 限 ， 这 样 就 不 要 再 创建 
新 的 serviceaccount， 当 然 你 也 可 以 自己 创建 新 的 serviceaccount， 然 后 给 它 
admin 权 限 


e JSONPath 手册 
e Kubernetes 中 的 认证 
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Kubernetes 中 的 用 户 与 身份 认证 授权 


安装 集群 的 时 候 我 们 在 master 节点 上 生成 了 一 堆 证 书 、token， 还 在 kubelet 的 

用 到 了 bootstrap token， 安 装 各 种 应 用 时 ， 为 了 能 够 与 API server 通信 创建 
了 各 种 service account， 在 Dashboard 中 使 用 了 kubeconfig S token AE > ABA 

这 些 都 属于 什么 认证 方式 ?了 如何 区 分 用 户 的 ?我 特地 翻译 了 下 这 篇 官方 文档 ， 想 你 
看 了 之 后 你 将 找到 答案 。 


重点 查看 bearer token 和 HTTP 认证 中 的 token 使 用 ， 我 们 已 经 有 所 应 用 ， 如 使 
A kubeconfig Stoken3t 47 M P Jr 433 3X 9 


认识 Kubernetes 中 的 用 户 


Kubernetes 集群 中 包含 两 类 用 户 : 一 类 是 由 Kubernetes 管理 的 service account ， 
另 一 类 是 普通 用 户 。 


普通 用 户 被 假定 为 由 外 部 独立 服务 管理 。 管 理 员 分 发 私 钥 ， 用 户 存储 (如 
Keystone 或 Google 帐户 ) ， 甚 至 包含 "ree pepe 文件 。 在 这 方面 ， 
Kubernetes 没有 代表 普通 用 户 帐 户 的 对 象 。 无 法 通过 API 调用 的 方式 向 集群 中 添 
加 普通 用 户 。 


854 8) > service account 是 由 Kubernetes API 管理 的 帐户 。 它 们 都 绑 定 到 了 特定 

的 namespace， 并 由 API server 自动 创建 ， 或 者 通过 AP| 调 用 手动 创建 。Service 
account 关联 了 一 套 赁 证， 存储 在 ”Secret ， 这 些 凭证 同时 被 挂 载 到 pod 中， 从 

而 允许 pod 4 kubernetes API 之 间 的 调用 。 


API 请求 被 绑 定 到 普通 用 户 或 serivce account 上 ， 或 者 作为 匿名 请 求 对 待 。 这 意味 
pipi pK MAPA. res en 

点 上 的 kubelet ， 到 控制 平面 的 成 员 ， 都 必须 在 向 API Server 发 出 请 求 时 进 

身份 验证 ， 或 者 被 视 为 匿名 用 户 。 


认证 策略 


Kubernetes 4% M Z P 3% i£ 4$ ^ bearer token、 身 份 验证 代理 或 者 HTTP 基本 身份 验 
证 等 身份 认证 插件 来 对 API 请 求 进行 身份 验证 。 当 有 HTTP 3 KR X 3X 8| API server 
时 ， 插 件 会 党 试 将 以 下 属性 关联 到 请 求 上 : 


e 用 户 名 : 标识 最 终 用 户 的 字符 串 。 人 常用 值 可 能 是 kube-admin 或 
jane@example.com “。 
。 UID : 标识 最 终 用 户 的 字符 串 ， 比 用 户 名 更 加 一 致 县 唯一。 
e 组: i ae IA P 2248 KK AY po 
e 额外 字段 : 包含 其 他 有 用 认证 信息 的 字符 串 列 表 的 映射 。 
所 有 的 值 对 于 认证 系统 都 是 不 透明 的 ， 只 有 授权 人 才能 解释 这 些 值 的 重要 含义 。 
您 可 以 一 次 性 启用 多 种 身份 验证 方式 。 通 常 使 用 至 少 以 下 两 种 认证 方式 : 
e 服务 帐户 的 service account token 
e 至 少 一 种 其 他 的 用 户 认证 的 方式 
启用 了 多 个 认证 模块 时 ， 第 一 个 认证 模块 成 功 认证 后 将 短路 请 求 ， 不 会 进行 第 二 
a o API server 不 会 保证 认证 的 顺序 。 


system:authenticated 组 包含 在 所 有 已 验证 用 户 的 组 列表 中 。 


与 其 他 身份 验证 协议 (LDAP、SAML、Kerberos、x509 方案 等 ) 的 集成 可 以 使 用 
身份 验证 代理 或 身份 验证 webhook 来 实现 。 


X509 客户 端 证 书 


通过 将 --client-ca-file=SOMEFILE 选项 传递 给 API server 来 启用 客户 端 证 书 
认证 。 引 用 的 文件 必须 包含 一 个 或 多 个 证 书 颁发 机 构 ， 用 于 验证 提交 给 API server 
的 客户 端 证 书 。 如 果 客 户 端 证 书 已 提交 并 验证 ， 则 使 用 subject 的 Common 
Name (CN) 作为 请 求 的 用 户 名 。 从 Kubernetes 1.4 开 始 ， 客 户 端 证 书 还 可 以 使 用 
organization 字段 来 指示 用 户 的 组 成 员 身 份 。 要 为 用 户 包 含 多 个 组 成 员 身 

， 请 在 证 书 中 包含 多 个 organization 字段 。 


例如 ， 使 用 openssl 命令 工具 生成 用 于 签名 认证 请 求 的 证 书 : 


openssl req -new -key jbeda.pem -out jbeda-csr.pem -Subj "/CN=jb 
eda/O-app1/0-app2" 


这 将 为 一 个 用 户 名 为 "beda' 的 CSR， 属 于 两 个 组 ‘人 app1” 和 “app2”。 


如 何 生 成 客户 端 证 书 请 参阅 附录 。 


$$ 4& Token 文件 


当 在 命令 行 上 指定 --token-auth-file=SOMEFILE 选项 时 ，API server 从 文件 
读 取 bearer token。 目 前 ，token 会 无 限期 地 持续 下 去 ， 并 且 不 重新 启动 API 
server 的 话 就 无 法 更 改 令 牌 列表 。 


token 文件 是 一 个 csv 文件 ， 每 行 至 少 包 念 三 列 : token、 用 户 名 、 用 户 uid， 其 次 
是 可 选 的 组 名 。 请 注意 ， 如 果 您 有 多 个 组 ， 则 该 列 必须 使 用 双 引 号 。 


token, user, uid, "groupi, group2, group3" 


在 请 求 中 放置 Bearer Token 


当 使 用 来 自 http 客户 端的 bearer token I} > API server HZ Authorization 
header 中 包含 Bearer token 的 值 。Bearer token 必须 是 一 个 字符 串 序列 ， 只 
需 使 用 HTTP 的 编码 和 引用 功能 就 可 以 将 其 放 入 到 HTTP header 中 。 例 如 : 如 果 
bearer token Æ 31ada4fd-adec-460c-809a-9e56ceb75269 ， 那 么 它 将 出 现在 
HTTP header 中 ， 如 下 所 示 : 


Authorization: Bearer 31ada4fd-adec-460c-809a-9e56ceb75269 


Bootstrap Token 
该 功能 仍 处 于 alpha 版 本 。 


为 了 简化 新 集群 的 初始 化 引导 过 程 ，Kubernetes 中 包含 了 一 个 名 为 Bootstrap 
Token 的 动态 管理 的 bearer token。 这 些 token 使 用 Secret 存储 在 kube- 
system namespace 中 ， 在 那里 它们 可 以 被 动态 管理 和 创建 。Controller Manager 
中 包含 了 一 个 TokenCleaner 控制 器 ， 用 于 在 bootstrap token 过 期 时 删除 将 其 删 


E 一 


ken 的 形式 是 [a-z0-9]{6}.[a-z0-9]{16} 。 第 一 部 分 是 Token ID， 第 


这 些 to 
部 分 是 Token Secret。 您 在 HTTP header 中 指定 的 token 如 下 所 示 : 


Authorization: Bearer 781292.db/7bc3a58fc5f07e 


在 API server 的 启动 参数 中 加 上 --experimental-bootstrap-token-auth 4% 
志 以 启用 Bootstrap Token Authenticator。 您 必须 通过 Controller Manager 上 的 - 
-controllers 标志 启用 TokenCleaner 控制 器 ， 如 -- 
controllers=*,tokencleaner 。 如 果 您 使 用 它 来 引导 集群 ， kubeadm 会 为 您 
完成 。 
认证 者 认证 为 system:bootstrap:<Token ID» 。 被 包含 在 
system:bootstrappers 组 中 。 命 名 和 组 是 有 意 限 制 用 户 使 用 过 去 的 bootstap 
token。 可 以 使 用 用 户 名 和 组 ( kubeadm 使 用 ) 来 制定 适当 的 授权 策略 以 支持 引 
导 集 群 。 


有 关 Bootstrap Token 身份 验证 器 和 控制 器 的 更 深入 的 文档 ， 以 及 如 何 使 用 
kubeadm 管理 这 些 令 牌 ， 请 参阅 Bootstrap Token » 


静态 均码 文件 


通过 将 --basic-auth-file=SOMEFILE 选项 传递 给 API server 来 启用 基本 身份 
验证 。 目 前 ， 基 本 身份 验证 凭证 将 无 限期 地 保留 ， 并 且 密 码 在 不 重新 启动 API 服 务 
器 的 情况 下 无 法 和 更改。 请 注意 ， 为 了 方便 起 见 ， 目 前 支持 基本 身份 验证 ， 而 上 述 模 
式 更 安全 更 容 多 使用。 


基本 身份 认证 是 一 个 csv 文件 ， 至 少 包含 3 列 : 密码 、 用 户 名 和 用 户 ID。 在 
Kubernetes 1.6 和 更 高 版 本 中 ， 可 以 指定 包含 以 如 号 分 隔 的 组 名 称 的 可 选 第 四 列 。 
双 引 号 


如 果 您 有 多 个 组 ， 则 必须 将 第 四 列 值 用 双 引 号 〈“) 括 起 来 ， 请 参阅 以 下 示例 : 


password, user,uid, "group1, group2, group3" 


当 使 用 来 自 HTTP 客户 端的 基本 身份 验证 时 ，API server $ € Authorization 
header 中 包含 Basic BASE64ENCODED(USER:PASSWORD) 的 值 。 


Service Account Token 


Service account 是 一 个 自动 启用 的 验证 器 ， 它 使 用 签名 的 bearer token 来 验证 请 
求 。 该 插件 包括 两 个 可 选 的 标志 : 


e --service-account-key-file 一 个 包含 签名 bearer token 的 PEM 编码 文 
件 。 如 果 未 指定 ， 将 使 用 API server 的 TLS 私 钥 。 
e --service-account-lookup 如 果 启 用 ， 从 API 中 删除 掉 的 token 将 被 撤 


Service account 通常 API server 自动 创建 ， 并 通过 ServiceAccount 注入 控制 


X 


器 关联 到 集群 中 运行 的 Pod 上 。Bearer token 挂 载 到 pod 中 众所周知 的 位 置 ， 并 
允许 集群 进程 与 API server 通信 。 帐户 可 以 使 用 PodSpec 的 
serviceAccountName 字段 显 式 地 与 Pod 关 联 。 


注意 : serviceAccountName 通常 被 省 略 ， 因 为 这 会 自动 生成 。 


apiVersion: apps/vibeta2 
kind: Deployment 
metadata: 
name: nginx-deployment 
namespace: default 
Spec: 
replicas: 3 
template: 
metadata: 
spec: 
containers: 
- name: nginx 
image: nginx:1.7.9 
serviceAccountName: bob-the-bot 


Service account bearer token 在 集群 外 使 用 也 是 完全 有 效 的 ， 并 且 可 以 用 于 为 希望 
与 Kubernetes 通信 的 长 期 运行 作业 创建 身份 。 要 手动 创建 service account， 只 需 
要 使 用 kubectl create serviceaccount (NAME) 命令 。 这 将 在 当前 的 
namespace 和 相关 连 的 secret 中 创建 一 个 service account ° 


$ kubectl create serviceaccount jenkins 
serviceaccount "jenkins" created 

$ kubectl get serviceaccounts jenkins -o yaml 
apiVersion: vi 

kind: ServiceAccount 

metadata: 

secrets: 

- name: jenkins-token-1yvwg 


创建 出 的 secret 中 拥有 API server 的 公共 CA 和 前 面 的 JSON Web 
Token (JWT) 。 


$ kubectl get secret jenkins-token-1yvwg -o yaml 
apiVersion: vi 
data: 
ca.crt: (APISERVER'S CA BASE64 ENCODED) 
namespace: ZGVmYXVsdA-- 
token: (BEARER TOKEN BASE64 ENCODED) 
kind: Secret 
metadata: 


type: kubernetes.io/service-account-token 


: 所 有 值 是 基于 base64 编码 的 ， 因 为 secret 总 是 基于 base64 编码 。 


经 过 签名 的 JWT 可 以 用 作 bearer token 与 给 定 的 service account 进行 身份 验证 。 
请 参阅 上 面 关于 如 何在 请 求 中 放置 bearer token。 通 常情 况 下 ， 这 些 secret 被 挂 
载 到 pod 中 ， 以 便 对 集群 内 的 API server 进行 访问 ， 但 也 可 以 从 集群 外 访问 。 


Service account 验证 时 用 户 名 system:serviceaccount: (NAMESPACE) : 
(SERVICEACCOUNT) ， 被 指定 到 组 system:serviceaccounts 和 
system:serviceaccounts: (NAMESPACE) ° 


注意 : 由 于 service account 的 token 存储 在 secret 中 ， 所 以 具有 对 这 些 secret 的 
读 取 权限 的 任何 用 户 都 可 以 作为 service account 进行 身份 验证 。 授 予 service 
account 权限 和 读 取 secret 功能 时 要 谨 懂 。 


OpenID Connect Token 


OpenID Connect 是 由 OAuth2 供应 商 提供 的 OAuth2 > 4$ %'] Æ Azure Active 
Directory ` Salesforce 和 Google ° 3} OAuth2 协议 的 主要 扩展 是 返回 一 个 称 作 ID 
Token 的 格外 字段 。 该 token 是 一 个 JSON Web Token (JWT) ， 有 服务 器 签名 ， 
具有 众所周知 的 字段 ， 如 用 户 的 电子 邮件 。 


为 了 识别 用 户 ， 认 证 者 使 用 OAuth2 token 响应 中 的 id token (而 不 是 
access token ) 作为 bearer token。 请 参阅 上 面 的 关于 将 token 置 于 请 求 中 。 
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图 片 - Kubernetes OpenID Connect Flow 


1. 登陆 到 您 的 身份 提供 商 


. 您 的 身份 提供 商 将 为 您 提供 一 个 access token ， 一 个 id token 和 一 个 


refresh_token 

当 使 用 kubectl 时 ， 使 用 --token 标志 和 id token ， 或 者 直接 加 入 
到 您 的 kubeconfig 文件 中 

kubectl 在 调用 API server 时 将 id token & HTTP header 中 


4 
5. API server 将 通过 检查 配置 中 指定 的 证 书 来 确保 JWT 签名 有 效 
6. 
7 
8 
9 


检查 以 确保 id token 没有 过 期 


.确保 用 户 已 授权 
. 授权 API server 后 向 kubectl 


kubectl 向 用 户 提 供 反 馈 


由 于 所 有 需要 验证 您 身份 的 数据 都 在 id _token 中 ，Kubernetes 不 需要 向 身份 提 
供 商 “phone home”。 在 每 个 请 求 都 是 无 状态 的 模型 中 ， 这 为 认证 提供 了 非常 可 扩 
展 的 解决 方案 。 它 确实 提供 了 一 些 挑 战 : 


1. 


2. 


3. 


Kubernetes A "web 接口 “来 出 发 验证 进程 。 没 有 浏览 器 或 界面 来 收集 赁 
据 ， 这 就 是 为 什么 您 需要 首先 认证 您 的 身份 提供 商 。 

id token 无 法 撤销 ,就 像 一 个 证 书 ， 所 以 它 应 该 是 短暂 的 (只 有 几 分 
钟 )， 所 以 每 隔 几 分 钟 就 得 到 一 个 新 的 令 牌 是 非常 烦人 的 。 

没有 使 用 kubectl proxy 命令 或 注入 id token 的 反 向 代理 ， 无 法 简单 
地 对 Kubernetes dashboard 进行 身份 验证 。 


配置 API Server 


要 尼 用 该 插件 ， 需 要 在 API server 中 配置 如 下 标志 : 


参数 描述 示例 
允许 API server 发 现 公共 签名 
密 钥 的 提供 者 的 URL。 只 接受 
使 用 https:// 的 方案 。 通 常 
z 44 共 2: tr , ~ aj 4 " 
UR CE 1 T i . https://accounts.google.c 
poem a https://accounts.google.com known/openid-configuratior 
7 ; 是 https://accounts.google 
"https://login.salesforce.com" ° = Hed 
这 个 URL 应 该 指向 下 面 的 
.well-known/openid- 
configuration 
- -Oidc- Sa B HS 
7 必须 为 其 颁发 的 客 
client- 所 有 9 token 必须 为 其 颁发 的 客 kubernetes 
JWT 声 明 使 用 的 用 户 名 。 默 认 情 
况 下 ， sub 是 最 终 用 户 的 唯一 
id 标识 符 。 管 理 员 可 以 选择 其 他 声 
明 ， 如 email 或 name * Æ süb 
claim 体 取 决 于 他 们 的 提供 者 S 
过 ， email 以 外 的 其 他 声明 将 
以 发 行者 的 URL 作为 前 级 ， 以 
防止 与 其 他 插件 命名 冲突 。 
--oidc- JWTP 9I JA A LP 28. » she FR E 
groups- 命 存在 ， 它 必须 是 一 个 字符 串 数 groups 
claim ZB o 
RE 用 来 签名 您 的 身份 提供 商 的 网 络 
PEE CA 证 书 的 路 径 。 默 认为 主机 的 /etc/kubernetes/ssl/kc-ce 
Sk CA ° 
如 果 为 --oidc-username-claim 选择 了 除 email 以 外 的 其 他 声明 ， 则 该 值 将 


以 --oidc-issuer-url 作为 前 级， 以 防止 与 现 有 Kubernetes 名 称 (例如 
system:users ) 冲突 。 例 如 ， 如 果 提 供 商 网 址 是 https:Waccounts.google.com ， 


而 用 户 名 声明 映射 到 jane ， 则 插件 会 将 用 户 身份 验证 为 : 


https://accounts.google.com#jane 


重要 的 是 ，API server 不 是 OAuth2 6 P 35 » 而 只 能 配置 为 信任 单个 发 行者 。 这 允 
许 使 用 Google 等 公共 提供 者 ， 而 不 必 信 任 第 三 方 发 行 的 凭据 。 和 希望 利用 多 个 
OAuth 客户 端的 管理 员 应 该 探索 支持 azp (授权 方 ) 声明 的 提供 者 ， 这 是 允许 一 
个 客户 端 代 表 另 一 个 客户 端 发 放 令 牌 的 机 制 。 


Kubernetes 不 提供 OpenID Connect 身份 提供 商 。 您 可 以 使 用 现 有 的 公共 OpenID 
Connect 标识 提供 程序 (例如 Google 或 其 他 ) 。 或 者 ， 您 可 以 运行 自己 的 身份 提 
供 程 序 ， 例 如 CoreOS dex、Keycloak、CloudFoundry UAA 或 Tremolo Security 
的 OpenUnison。 


对 于 身份 提供 商 能 够 适用 于 Kubernetes > 3528 i 240 F & fF : Kubernetes it must: 


1. 支持 OpenID connect KIL ; 不 必 是 全 部 。 
2. 使 用 非 过 时 密码 在 TLS 中 运行 
3. 拥有 CA 签名 证 书 (即使 CA 不 是 商业 CA 或 自 签名 ) 


有 关上 述 要 求 3 的 说 明 ， 需 要 CA 签名 证 书 。 如 果 您 部 署 自己 的 身份 提供 商 (而 不 
是 像 Google 或 Microsoft 之 类 的 云 提供 商 ) ， 则 必须 让 您 的 身份 提供 商 的 Web AR 
务 器 证 书 由 CA 标志 设置 为 TRUE 的 证 书签 名 ， 即 使 是 自 签 名 的 。 这 是 由 于 
GoLang 的 TLS 客户 端 实 现 对 证 书 验证 的 标准 非常 严格 。 如 果 您 没有 CA ， 可 以 
使 用 Coreos 团队 的 这 个 脚本 创建 一 个 简单 的 CA 和 一 个 签名 的 证 书 和 密 钥 对 。 


或 者 你 可 以 使 用 这 个 类 似 的 脚本 来 生成 更 长 寿命 和 更 长 的 SHA256 证 书 密 铀 。 
针对 特定 系统 的 安装 说 明 : 


e UAA 
e Dex 
e OpenUnison 


使 用 kubectl 
选项 1 - OIDC 身份 验证 器 


第 一 个 选项 是 使 用 oidc 身份 验证 器 。 此 身份 验证 程序 将 您 的 
id token ^ refresh token 和 您 的 OIDC client secret 自动 刷新 您 的 
token。 一 旦 您 对 身份 提供 者 进行 了 身份 验证 : 


kubectl config set-credentials USER_NAME \ 
--auth-provider=oidc \ 
--auth-provider-arg-idp-issuer-url-( issuer url ) \ 
--auth-provider-arg-client-id-( your client id ) \ 
--auth-provider-arg-client-secret-( your client secret ) \ 
--auth-provider-arg-refresh-token-( your refresh token ) \ 
--auth-provider-arg-idp-certificate-authority-( path to your 
ca certificate ) \ 
--auth-provider-arg-id-token-( your id token ) \ 
--auth-provider-arg-extra-scopes-( comma separated list of sc 
opes to add to "openid email profile", optional ) 


例如 ， 在 向 身份 提供 者 进行 身份 验证 之 后 运行 以 下 命令 : 


kubectl config set-credentials mmosley \ 

--auth-provider-oidc \ 

- -auth-provider -arg=idp-issuer -url=https://oidcidp.tremo 
lo.lan:8443/auth/idp/OidcIdP \ 

--auth-provider-arg-client-id-kubernetes \ 

- -auth-provider -arg=client -secret=1db158f6 -177d -4d9c-8a8 
b-d36869918ec5 \ 

- -auth-provider -arg=refresh-token=qibKLFOyUiosT fawzA93Tz 
ZIDzH2TNa2SMmOzEiPKTUWwMEGBkEo6Sq15yUWVBSWpKUGphaWpxSVAf ekBOZbBha 
EW+V1FUeVRGcluyVF5JT4+haZmPs1luFoFu5xXkpxXk5BxqHega4GAX1F+ma+vmyY pFc 
He5eZR+S1BFpZKtQA= \ 

- -auth-provider -arg=idp-certificate-authority=/root/ca.p 
em \ 

--auth-provider-arg-extra-scopes-groups \ 

- -auth-provider-arg-id-token-eyJraWQiOiJDTjivaWRjaWRwLnR 
yZWivbG8ubGFuLCBPVT1EZW1vLCBPPVRybWVvbG8gU2Vj dxXJpdHksIEw9QxXJsawW5 
ndG9uLCBTVD1WaXJnaW5pYSwgQz1VUy1DT jirdwJLLWNnhLTEyMDIXNDC5MjEwMzy 
wNzMyMTUyIiwiYWxnIjoiUlMyNTYifQ.eyJpc3MiOiJodHRwczovL29pZGNpZHAu 
dHJlbw9sby5sYWA6O0DQOMy9hdXROL21kcC9PaWRj SWwRQIiwiYXVkIjoia3ViZXJu 
ZXRlcyIsImV4AcCIGMTQAMZzUOOTUXxMSwianRpIjoiMm96US15TXdFcHVAWDlHZUhQ 
dyihZyIsImlhdCI6MTQAMzUOOTQi1MSwibmJmI;joxNDgzNTQ5MzMXLCJzdWIiOilO 
YWViMzdiYSi1iNjQi1LTQAZmQt YWIZzMCOxYTAxZWUOMWUyMTgifQ.w6p4J. 6qQ1HzT 
G9nrEOrubxIMb9K5hzcMPXxc9IxPx2K4x091-oFiUw93daH3mbpluP6K7eOE6txBu 
RVfEcpJSwlelsOsW8gb8VJcnzMS9EnZpeAOtW p-mnkFc3VcfyXuhe5R3G7aab5d8 
uHv70yJ9Y3-UhjiN9EhpMdfPAOEB9f YKKkJRzF7utTTIPGrSaSU6d2pcpf YKaxIw 
ePzEkTADfcQthoZdy9ucNvvLoi1DIC-UocFD8HLs8LYKEqSxQvOcvnThbOb J9af 7 
1EwmuE21fO5KzMW20KtAegeti1gnldOosPtziG5EwvaQ401-RPQzPGMVBldO zMCA 
wZttJ4knw 


将 产生 下 面 的 配置 : 


users: 
- name: mmosley 
user: 
auth-provider: 
config: 

client-id: kubernetes 

client-secret: 1db158f6-177d-4d9c -8a8b-d36869918ec5 

extra-scopes: groups 

id-token: eyJrawQiOiJDTji1vaWRjaWRwLnRyZW1vbG8ubGFUuLCBPVT 
1EZW1vLCBPPVRybWVvbG8gU2V j dXJpdHksIEwW9QXJsaWb5ndG9uLCBTVD1WaXJnaW 
5pYSwgQz1VUy1DTjirdwJlLWNhLTEyMDIXxNDC5MjEwMzYwNzMyMTUyIiwiYWxnI;j 
oiUlMyNTYifQ.eyJpc3MiOiJodHRwczovL29pZGNpZHAudHJ1lbW9sby5sYWA460DQ 
OoMy9hdXRoL21kcC9PaWRj SWRQTiwiYXVkIjoia3ViZXJuZXRlcyIsImV4cCI6MTQ 
4MzUOOTUxMSwianRpIjoiMm96US15TXdFcHVAWDlIHZUhQdyd1hZyIsImlhdCIGMTQ 
4MzUOOTQ1MSwibmJmIjoxNDgzNTQB5MzMxLCJzdWIiOilOYWViMzdiYS1iNjQi1LTQ 
AZmQt YWIzMCOxYTAxZWUOMWUyMTgifQ.w6p4J  6qQ1HzTG9nrEOrubxIMb9Kb5hzc 
MPXc9IXxPX2K4x091 -oFiUw93daH3m5pluP6K7eOE6txBuRVfEcpJSwlelsOsW8gb 
8VJcnzMS9EnZpeAOtW p-mnkFc3VcfyXuhe5R36G7aabd8uHv70y J9Y3-UhjiN9Eh 
pMdfPAoEB9fYKKkJRzF7utTTIPGrSaSU6d2pcpfYKaxIwePzEkTA4DfcQthozdy9u 
CNvvLoiiDIC -UocFD8HLS8LYKEqSxQvOcvnThbObJ9af71EwmuE21f O5KzMW20Kt 
Aegetignld0osPtz1G5EwvaQ401-RPQZPGMVB1d0_ZMCAwZttJ4knw 

idp-certificate-authority: /root/ca.pem 

idp-issuer-url: https://oidcidp.tremolo.lan:8443/auth/id 
p/OidcIdP 

refresh-token: q1bKLFOyUiosTfawzA93TzZIDzH2TNa2SMmOzEiPK 
TUwME6BkE06Sq15yUWVBSWpKUGphaWpxSVAf ekBOZbBhaEW- V 1FUeVRGcluyVF5J 
T4-hazmPsluFoFu5XkpXk5BXq 

name: oidc 


一 旦 您 的 id token 过 期 ， kubectl 将 使 用 refresh token 刷新 
id token ， 然 后 在 kube/.config 文件 的 client secret 中 存储 
id token 的 值 和 refresh token 的 新 值 。 


选项 2 -使 用 --token 选项 


可 以 在 kubectl 命令 的 --token 选项 中 传 入 token。 简 单 的 拷贝 和 复制 
id token 到 该 选项 中 : 


kubectl --token=eyJhbGci0iJSUZI1NiJ9.eyJpc3Mi0iJodHRwczovL21sYi5 
OcmVtb2xvLmxhbj oA4MDQzL2F1dGgvaWRwL29pZzGMiLCJhdWQiOiJrdWJlcm5ldGV 
ZIiwiZxXhwIj oxNDcONTk2NjY5LCJqdGki0iI2RDUZNXOXUEpFNj JOR3QxaWVy Ym9 
RIiwiawWFOIjoxNDCONTk2MzZY5LCJuYmYi0jEONZQ1OTYyNDkKSInN1Yil6Im13aw5 
kdSIsInVzZXJfcm9sZSI6WyJic2VycyIsIm5ldy1uYW1lc3BhY2Utdmlld2VyIl0O 
sImvtYWwlsIjoibXdpbmRi1QG5vbw9yZWplZGkuY29tInO.f2As579n9VNoaKzoF -d 
OQGmXkFKf1FMyNVO -va. B63jn-. n9LGSCca. 6IVMP8pO-ZbAKVRqGyTPOrS3HkHxY 
y5c81AnIh8ijarruczl-TK yF5akjSTHFZD-OgRzlevBDiH8Q79NAr-KkyOPAiIXS 
81Y9Vnjch5MF74Zx0c3alKJHJUnnpj IACByfF2SCaYZbWFMUNat -K1PaUk5 -ujMB 
G7yYnr95xD-63n8CO8teGUAAEMXx6zRjzfhnhbzX-ajwZLGwGUBTAWq jMs 70 -6a7 . 
8gzmLZb2azicZynkFRj2BaCkVT3A2RrjeEwZEtGX1MqKJ1 I2ulrOVsYx01 yD35 
-rw get nodes 


Webhook Token ZA 


Webhook 认证 是 用 来 认证 bearer token 的 hook 。 


e --authentication-token-webhook-config-file 有 是 一 个 用 来 描述 如 何 访 
问 远程 Webhook 服务 的 kubeconfig 文件 。 

e --authentication-token-webhook-cache-ttl 缓存 身份 验证 策略 的 时 
间 。 默 认为 两 分 钟 。 


配置 文件 使 用 kubeconfig 文件 格式 。 文 件 中 的 "user" 指 的 是 API server 的 
webhook °’ "clusters" 是 指 远 程 服务 。 见 下 面 的 例子 : 


# clusters refers to the remote service. 


clusters: 
- name: name-of-remote-authn-service 
cluster: 
certificate-authority: /path/to/ca.pem # CA for ve 


rifying the remote service. 
server: https://authn.example.com/authenticate # URL of re 
mote service to query. Must use 'https'. 


# users refers to the API server's webhook configuration. 
users: 
- name: name-of-api-server 
user: 

client-certificate: /path/to/cert.pem # cert for the webho 
ok plugin to use 

client-key: /path/to/key.pem # key matching the c 
ert 


# kubeconfig files require a context. Provide one for the API se 
rver. 
current-context: webhook 
contexts: 
- context: 
cluster: name-of-remote-authn-service 
user: name-of-api-sever 
name: webhook 


当 客 户 端 尝试 使 用 bearer token 与 API server 进行 认证 是 ， 如 上 论述 ， 认 证 
webhook 用 饱含 该 token 的 对 象 查 询 远 程 服 务 。Kubernetes 不 会 挑战 缺少 该 
header 的 请 求 。 


请 注意 ，Webhook API 对 象 与 其 他 Kubernetes API 对 象 具 有 相同 的 版 本 控制 兼容 

性 规则 。 实 现 者 应 该 意识 到 Beta 对 象 的 宽松 兼容 性 承诺 ， 并 检查 请 求 的 

“apiVersion” 字段 以 确保 正确 的 反 序 列 化 。 此 外 ，API server 必须 启用 
authentication.k8s.io/vibetai API 扩展 组 ( --runtime config 


=authentication.k8s.io/vibetai=true ) ° 


The request body will be of the following format: 


{ 
"apiVersion": "authentication.k8s.io/vibetai", 
"kind": "TokenReview", 
"spec": { 


"token": "(BEARERTOKEN)" 


j 
} 


预计 远程 服务 将 填写 请 求 的 status 字段 以 指示 登录 成 功 。 响 应 主体 的 spec 
字段 被 忽略 ， 可 以 省 略 。 成 功 验证 后 的 bearer token 将 返回 : 


{ 


"apiVersion": "authentication.k8s.io/vibeta1", 
"kind": "TokenReview", 
"status": 4 
"authenticated": true, 
"user": ( 
"username": "janedoeQexample.com", 
"uid": "22". 
"groups": [ 
"developers", 
"ga" 
], 
"extra": { 
"extrafieldi": [ 
"extravaluei", 
"extravalue2" 


未 成 功 的 请 求 将 返回 : 


"apiVersion": "authentication.k8s.io/vibeta1", 
"kind": "TokenReview", 
"status": 4 

"authenticated": false 


j 
j 


HTTP 状 态 代码 可 以 用 来 提供 额外 的 错误 上 下 文 。 
认证 代理 


可 以 配置 API server 从 请 求 header 的 值 中 识别 用 户 ， 例 如 X-Remote-User 。 这 
样 的 设计 是 用 来 与 请 求 header 值 的 验证 代理 结合 使 用 。 


e --requestheader-username-headers 必需 ， 大 小 写 敏感 。 按 header 名 称 
和 顺序 检查 用 户 标识 。 包 含 值 的 第 一 个 header 将 被 作为 用 户 名 。 


e --requestheader-group-headers 1.6 以 上 版 本 。 可 选 。 大 小 写 敏感 。 建 
议 为 “X-Remote-Group”。 按 header 名 称 和 顺序 检查 用 户 组 。 所 有 指定 的 
header 中 的 所 有 值 都 将 作为 组 名 。 

e --requestheader-extra-headers-prefix 1.6 以 上 版 本 。 可 选 ， 大 小 写 敏 
感 。 建 议 为 “X-Remote-Extra-"。 标题 前 级 可 用 于 查找 有 关 用 户 的 额外 信息 

(通常 由 配置 的 授权 插件 使 用 ) 。 以 任何 指定 的 前 组 开头 的 header 都 会 删除 
314& header 名 称 的 其 余部 分 将 成 为 额外 的 键 值 ， 而 header 值 则 是 额外 的 
值 。 


例如 下 面 的 配置 : 


- -requestheader - username -headers=X-Remote-User 
--requestheader - group -headers=X-Remote-Group 
- -requestheader -extra-headers-prefix=X-Remote-Extra- 


该 请 求 : 


GET / HTTP/1.1 

X-Remote-User: fido 
X-Remote-Group: dogs 
X-Remote-Group: dachshunds 
X-Remote-Extra-Scopes: openid 
X-Remote-Extra-Scopes: profile 


将 产生 如 下 的 用 户 信息 : 


name: fido 
groups: 
- dogs 
- dachshunds 
extra: 
scopes: 
- openid 
- profile 


为 了 防止 header 欺骗， 验证 代理 需要 在 验证 请 求 header 之 前 向 API server 提供 
有 效 的 客户 端 证 书 ， 以 对 照 指定 的 CA 进行 验证 。 


e --requestheader-client-ca-file 必需 。PEM 编码 的 证 书包 。 在 检查 用 
户 名 的 请 求 header 之 前 ， 必 须 针 对 指定 文件 中 的 证 书 颁发 机 构 提 交 并 验证 有 
效 的 客户 端 证 书 。 


e --requestheader-allowed-names 可 选 。Common Name (cn) 列表 。 如 
果 设 置 了 ， 则 在 检查 用 户 名 的 请 求 header 之 前 ， 必 须 提 供 指 定 列表 中 
Common Name (cn) 的 有 效 客 户 端 证 书 。 如 果 为 室 ， 则 允许 使 用 任何 
Common Name ° 


Keystone X 


过 在 启动 过 程 中 将 --experimental-keystone-url=<AUthURL> 选项 传递 给 
API server 来 启用 Keystone 认证 。 该 插件 在 
本 中 实 
现 ， 目 前 使 用 基本 身份 验证 通过 用 户 名 和 密码 验证 用 户 。 


如 果 您 为 Keystone 服务 器 配置 了 自 签名 证 书 ， 则 在 启动 Kubernetes API server 时 
可 能 需要 设置 --experimental-keystone-ca-file=SOMEFILE 选项 。 如 果 您 设 

置 了 该 选项 ，Keystone 服务 器 的 证 书 将 由 experimental-keystone-ca-file 中 
某 个 权威 机 构 验证 。 和 否则 ， 证 书 由 主机 的 根 证 书 颁发 机 构 验证 e 


有 关 如 何 使 用 keystone 来 管理 项 目 和 用 户 的 详细 信息 ， 请 参阅 Keystone o B 
注意 ， 这 个 插件 仍 处 于 试验 阶段 ， 正 在 积极 开发 之 中 ， 并 可 能 在 后 续 版 本 中 进 
改 。 


请 参考 讨论 、 蓝 图 和 提出 的 改变 获取 更 多 信息 。 


匿名 请 


启用 时 ， 未 被 其 他 已 配置 身份 验证 方法 拒绝 的 请 求 将 被 视 为 匿名 请 求 ， 并 给 耶 
system:anonymous 的 用 户 名 和 system:unuthenticated 的 组 名 。 


例如 ， 在 配置 了 令 牌 认证 和 启用 了 匿名 访问 的 服务 器 上 ， 提 供 无 效 的 bearer token 
的 请 求 将 收 到 401 Unauthorized 错误 。 提 供 bearer token 的 请 求 将 被 视 为 匿名 
请 求 。 

在 1.5.1-1.5.x 版 本 中 ， 默 认 情 况 下 命名 访问 是 被 禁用 的 ， 可 以 通过 传递 -- 
anonymous-auth-false 选项 给 API server 来 启用 。 


在 1.6+ 版 本 中 ， 如 果 使 用 AlwaysAllow 以 外 的 授权 模式 ， 则 默认 局 用 匿名 访 


问 ， 并 且 可 以 通过 将 --anonymous-auth=false 选项 传递 给 API 服 务 器 来 禁用 。 
从 1.6 开始 ，ABAC 和 RBAC 授权 人 需要 明确 授权 system:annoymous 或 


system:unauthenticated 组 ， 因 此 授予 对 * APR * 组 访问 权 的 传统 策略 
规则 不 包括 匿名 用 户 。 


用 户 模 拟 


用 户 可 以 通过 模拟 header 充当 另 一 个 用 户 。 该 请 求 会 覆盖 请 求 认证 的 用 户 信 息 。 
例如 ， 管 理 员 可 以 使 用 此 功能 通过 暂时 模拟 其 他 用 户 并 查看 请 求 是 否 被 拒绝 来 调试 
授权 策略 。 


模拟 请 求 首 先 认证 为 请 求 用 户 ， 然 后 切换 到 模拟 的 用 户 信 息 。 


e 用 户 使 用 他 们 的 凭证 和 模拟 header 进行 API 调用 。 
e API server 认证 用 户 

e API server 确保 经 过 身份 验证 的 用 户 具 有 模拟 权限 。 
e 请 求 用 户 的 信息 被 蔡 换 为 模拟 值 

e. 请 求 被 评估 ， 授 权 作用 于 模拟 的 用 户 信息 。 


以 下 HTTP header 可 用 户 执行 模拟 请 求 : 


e Impersonate-User :充当 的 用 户 名 

e Impersonate-Group : 作为 组 名 。 可 以 多 次 使 用 来 设置 多 个 组 。 可 选 的 ， 需 
要 “Impersonate-User” 

e Impersonate-Extra-( extra name ) : 用 于 将 额外 字段 与 用 户 关联 的 动态 
header ° "T34 °- % -Æ “Impersonate-User” 


一 组 示例 header : 


Impersonate-User: jane.doe@example.com 

Impersonate-Group: developers 

Impersonate-Group: admins 

Impersonate-Extra-dn: cn=jane, ou=engineers, dc=example, dc=com 
Impersonate-Extra-scopes: view 

Impersonate-Extra-scopes: development 


当 使 用 kubectl  --as 标志 来 配置 Impersonate-User header 时， 可 以 
使 用 --as-group 标志 来 配置 Impersonate-Group header。 


$ kubectl drain mynode 
Error from server (Forbidden): User "clark" cannot get nodes at 
the cluster scope. (get nodes mynode) 


$ kubectl drain mynode --as-superman --as-group-system:masters 
node "mynode" cordoned 
node "mynode" draine 


为 模仿 用 户 、 组 或 设置 额外 字段 ， 模 拟 用 户 必 须 能 够 对 正在 模拟 的 属性 的 种 类 (“用 
户 ”，“ 组 ?等 ) 执行 “模拟 ”动词 。 对 于 启用 了 RBAC 授权 插件 的 集群 ， 以 下 
ClusterRole 包含 设置 用 户 和 组 模拟 header 所 需 的 规则 : 


apiVersion: rbac.authorization.k8s.io/vi 

kind: ClusterRole 

metadata: 
name: impersonator 

rules: 

- apiGroups: [""] 
resources: ["users", "groups", "serviceaccounts"] 
verbs: ["impersonate"] 


额外 的 字段 被 评估 为 资源 “Userextras” 的 子 资 源 。 为 了 允许 用 户 使 用 额外 字段 
"scope" 的 模拟 header’? LATA PAP AG: 


apiVersion: rbac.authorization.k8s.io/vi 
kind: ClusterRole 
metadata: 
name: scopes-impersonator 
# Can set "Impersonate-Extra-scopes" header. 
- apiGroups: ["authentication.k8s.io"] 
resources: ["userextras/scopes"] 
verbs: ["impersonate"] 


€ 44 header 的 可 用 值 可 以 通过 设置 resourceNames 可 以 使 用 的 资源 来 限制 。 


apiVersion: rbac.authorization.k8s.io/v1 
kind: ClusterRole 
metadata: 
name: limited-impersonator 
rules: 
# Can impersonate the user "jane.doeQexample.com" 
apiGroups: [""] 
resources: ["users"] 
verbs: ["impersonate" ] 
resourceNames: ["jane.doe@example.com" ] 


dk 


Can impersonate the groups "developers" and "admins" 
apiGroups: [""] 

resources: ["groups"] 

verbs: ["impersonate"] 

resourceNames: ["developers","admins"] 


# Can impersonate the extras field "scopes" with the values "vie 
Ww" and "development" 
- apiGroups: ["authentication.k8s.io"] 

resources: ["userextras/scopes"] 

verbs: ["impersonate"] 

resourceNames: ["view", "development" ] 


附录 


创建 证 书 

使 用 客户 端 证 书 进 行 身份 验证 时 ， 可 以 使 用 现 有 的 部 署 脚 本 或 通过 easyrsa 或 
openssl 手动 生成 证 书 。 

使 用 已 有 的 部 署 脚本 


已 有 的 部 署 脚本 在 cluster/saltbase/salt/generate-cert/make-ca- 
cert.sh ° 


执行 该 脚本 时 需要 传递 两 个 参数 。 第 一 个 参数 是 API server 的 IP 地 址 。 第 二 个 参 
数 是 IP 形式 的 主题 备用 名 称 列表 : IP:<ip-address> 或 DNS:<dns-name> ° 


该 脚本 将 生成 三 个 文件 : ca.crt 、 server.crt 和 server.key ° 
最 后 ， 将 一 下 参数 添加 到 API server 的 启动 参数 中 : 


e --client-ca-file=/srv/kubernetes/ca.crt 


e --tls-cert-file=/srv/kubernetes/server.crt 


e --tls-private-key-file=/srv/kubernetes/server .key 
easyrsa 
easyrsa 可 以 用 来 手动 为 集群 生成 证 书 。 


1. 下载， 解压， 并 初始 化 修补 版 本 的 easyrsa3 。 


curl -L -0 https://storage.googleapis.com/kubernetes-release 
/easy-rsa/easy-rsa.tar.gz 

tar xzf easy-rsa.tar.gz 

cd easy-rsa-master/easyrsa3 

./easyrsa init-pki 


2. 生成 CA (使 用 --batch 设置 为 自动 模式 。 使 用 --req-cn 设置 默认 的 
CN ) 


./easyrsa --batch "--req-cn=${MASTER_IP}@ date +%s`" build-c 
a nopass 


3. 生成 服务 器 证 书 和 密 钥 。 (build-server-full [文件 名 ] : 生成 一 个 键 值 对 ， 在 本 
地 为 客户 端 和 服务 器 签名 。) 


./easyrsa --subject-alt-name="IP:${MASTER_IP}" build-server- 
full server nopass 


4. 复制 pki/ca.crt , pki/issued/server.crt 和 
pki/private/server.key 到 您 的 目录 下 。 


. 将 以 下 参数 添加 到 API server 的 启动 参数 中 : 


Ol 


--client-ca-file=/yourdirectory/ca.crt 
--tls-cert-file=/yourdirectory/server.crt 
--tls-private-key-file-/yourdirectory/server.key 


openssl 


openssl 可 以 用 来 手动 为 集群 生成 证 书 。 


1. 生成 一 个 2048 bit 的 ca.key : 


openssl genrsa -out ca.key 2048 


2. 根据 ca.key 生成 一 个 ca.crt (使 用 -days 设置 证 书 的 有 效 时 间 ) 


openssl req -x509 -new -nodes -key ca.key -Subj "/CN=${MASTE 
R_IP}" -days 10000 -out ca.crt 


3. 生成 一 个 2048 bit 的 server.key : 


openssl genrsa -out server.key 2048 


4. 根据 server.key 生成 一 个 server.csr : 


openssl req -new -key server.key -subj "/CN=${MASTER_IP}" -o 
ut server.csr 


5. 根据 ca.key ` ca.crt 和 server.csr 生成 server.crt : 


openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -C 
Acreateserial -out server.crt -days 10000 


6. 查看 证 书 : 


openssl x509 -noout -text -in ./server.crt 


最 后 ， 不 要 忘 了 向 API server 的 启动 参数 中 增加 配置 。 


认证 API 


您 可 以 使 用 certificates.k8s.io API 将 x509 证 书 配置 为 用 于 身份 验证 ， 如 此 
处 所 述 。 


官方 v1.6 文 档 地 址 : https://v1-6.docs.kubernetes.io/docs/admin/authentication/ 官 
方 最 新 文档 地 址 : https://kubernetes.io/docs/admin/authentication/ 


译 者 : Jimmy Song 
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访问 Kubernetes 集群 


根据 用 户 部 署 和 暴露 服务 的 方式 不 同 ， 有 很 多 种 方式 可 以 用 来 访问 kubernetes 集 
群 。 

e 最 简单 也 是 最 直接 的 方式 是 使 用 kubectl 命令 。 

e 其 次 可 以 使 用 kubeconfig 文件 来 认证 授权 访问 API server。 

e 通过 各 种 proxy 经 过 端口 转发 访问 kubernetes 集群 中 的 服务 

e 使 用 Ingress， 在 集群 外 访问 kubernetes 集群 内 的 service 
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访问 集群 
第 一 次 使 用 kubectl 访问 


如 果 您 是 第 一 次 访问 Kubernetes API 的 话 ， 我 们 建议 您 使 用 Kubernetes 命令 行 工 
具 : kubectl 。 


为 了 访问 集群 ， 您 需要 知道 集群 的 地 址 ， 并 且 需 要 有 访问 它 的 赁 证。 通常 ， 如 果 您 
完成 了 那么 这 些 将 会 自动 设置 ， 或 者 其 他 人 为 您 部 署 的 集群 提供 并 给 您 
凭证 和 集群 地 址 。 


使 用 下 面 的 命令 检查 kubectl 已 知 的 集群 的 地 址 和 凭证 


$ kubectl config view 


关于 kubectl 命令 使 用 的 更 多 示例 和 完整 文档 可 以 在 这 里 找到 : kubectl 手册 


直接 访问 REST API 


Kubectl 处 理 对 apiserver 的 定位 和 认证 。 如 果 您 想 直 接 访 问 REST API， 可 以 使 用 
像 curl ^ wget 或 浏览 器 这 样 的 http 客户 端 ， 有 以 下 几 种 方式 来 定位 和 认证 : 


e. 以 proxy 模式 运行 kubectl 。 
o 推荐 方法 。 
o 使 用 已 保存 的 apiserver 位 置信 息 。 
o 使 用 自 签名 证 书 验证 apiserver 的 身份 。 没有 MTM (中 间 人 攻击 ) 的 可 
能 。 
o 认证 到 apiserver ° 
o 将 来 ， ， nd 负载 均衡 和 故障 转移 。 
直接 向 http 客户 端 提供 位 置 和 凭据 。 
o 替代 方法 。 
o 适用 于 通过 使 用 代理 而 混淆 的 某 些 类 型 的 客户 端 代码 。 
o 需要 将 根 证 书 导 入 浏览 器 以 防止 MITM 。 


使 用 kubectl proxy 


以 下 命令 作为 反 向 代理 的 模式 运行 kubectl o 它 处 理 对 apiserver 的 定位 并 进行 认 
TE © 


$ kubectl proxy --port-8080 & 


查看 关于 kubectl proxy 的 更 多 细节 。 


然后 您 可 以 使 用 curl > wget 或 者 浏览 器 来 访问 API， 如 下 所 示 : 


$ curl http://localhost:8080/api/ 
{ 


"versions": [ 
wya” 


] 
} 


不 使 用 kubectl proxy (1.3.x 以 前 版 本 ) 


通过 将 认证 token 直接 传递 给 apiserver 的 方式 ， 可 以 避免 使 用 kubectl proxy， 如 
下 所 示 : 


$ APISERVER-$(kubectl config view | grep server | cut -f 2- -d " 
gn | tr -d "n v) 

$ TOKEN=$(kubectl config view | grep token | cut -f 2 -d ":" | tr 
-d " E) 

$ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" -- 

insecure 


i 


"versions": [ 
Hay n 


[ 辐 I E) 
不 使 用 kubectl proxy (1.3.x 以 后 版 本 ) 


在 Kubernetes 1.3 或 更 高 版 本 中 ， kubectl config view 不 再 显示 token ° 使 
用 kubectl describe secret .， 获 取 default service account 的 token， 如 下 
所 示 : 


$ APISERVER-$(kubectl config view | grep server | cut -f 2- -d " 


en | tr -d " ") 

$ TOKEN=$(kubectl describe secret $(kubectl get secrets | grep d 

efault | cut -f1 -d ' ') | grep -E '^token' | cut -f2 -d':' | tr 
-d '\t') 


$ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" -- 
insecure 


{ 
"kind": "APIVersions", 
"versions": [ 
nq 
l; 
"serverAddressByClientCIDRs": [ 
"clientCIDR": "0.0.0.0/0", 
"serverAddress": "10.0.1.149 :443" 
} 
] 
} 


以 上 示例 使 用 --insecure 标志 。 这 使 得 它 容易 受到 MTM 攻击 。 Z kubectl 77 
问 集群 时 ， 它 使 用 存储 的 根 证 书 和 客户 端 证 书 来 访问 服务 器 。 (这 些 安装 

在 -/.kube HRY) 。 由 于 集群 证 书 通常 是 自 签名 的 ， 因 此 可 能 需要 特殊 配置 才 
能 让 您 的 http 客户 端 使 用 根 证 书 。 


对 于 某 些 群集 ，apiserver 可 能 不 需要 身份 验证 ; 可 以 选择 在 本 地 主机 上 服务 ， 或 者 
使 用 防火 墙 保护 。 对 此 还 没有 一 个 标准 。 配 置 对 API 的 访问 描述 了 群集 管理 员 如 何 
置 此 操作 。 这 种 方法 可 能 与 未 来 的 高 可 用 性 支持 相 冲 突 。 


Fa FETH le] API 
Kubernetes 支持 Go 和 Python & P 3 & ° 


Go € P 


e 要 获取 该 库 ， 请 运行 以 下 命令 : go get k8s.io/client-go/«version 
number>/kubernetes 请 参阅 https://github.com/kubernetes/client-go 以 查看 
支持 哪些 版 本 。 

e 使 用 client-go 客户 端 编程 。 请 注意 ，client-go 定义 了 自己 的 API 对 象 ， 因 此 
如 果 需 要 ， 请 从 client-go 而 不 是 从 主 存储 库 导 入 API 定义 ， 例 如 导入 

k8s.io/client-go/1.4/pkg/api/vi 是 正确 的 。 


Go 客户 端 可 以 使 用 与 kubectl 命令 行 工 具 相 同 的 kubeconfig 文件 来 定位 和 验证 
apiserver。 参 考官 方 示例 和 client-go 示例 。 


如 果 应 用 程序 在 群集 中 以 Pod 的 形式 部 署 ， 请 参考 下 一 节 。 


Python 客户 端 
要 使 用 Python client， 请 运行 以 下 命令 : pip install kubernetes 。 查 看 


Python 客户 端 库 页 面 获取 更 多 的 安装 选择 。 


Python 客户 端 可 以 使 用 与 kubectl 命令 行 工 具 相 同 的 kubeconfig 文件 来 定位 和 验 
证 apiserver。 参 考 该 示例 。 


其 他 语言 


还 有 更 多 的 客户 端 库 可 以 用 来 访问 API。 有 关 其 他 库 的 验证 方式 ， 请 参阅 文档 。 


在 Pod 中 访问 API 


在 Pod 中 访问 API 时 ， 定 位 和 认证 到 API server 的 方式 有 所 不 同 。 在 Pod 中 找到 
apiserver 地 址 的 推荐 方法 是 使 用 kubernetes DNS 名 称 ， 将 它 解析 为 服务 IP， 后 者 
又 将 被 路 由 到 apiserver。 

向 apiserver 认证 的 推荐 方法 是 使 用 service account 凭据 。 通 过 kube-system ， 
pod 与 service account 相关 联 ， 并 且 将 该 service account 的 凭据 (token) 放 入 该 
pod 中 每 个 容器 的 文件 系统 树 中 ， 位 于 


/var/run/secrets/kubernetes.io/serviceaccount/token ° 


如 果 可 用 ， 证 书包 将 位 于 每 个 容器 的 文件 系统 树 的 
/var/run/secrets/kubernetes.io/serviceaccount/ca.crt 位 置 ， 并 用 于 验 

证 apiserver 的 服务 证 书 。 

最 后 ， 用 于 namespace API 操作 的 默认 namespace 放 在 每 个 容器 中 的 


/var/run/secrets/kubernetes.io/serviceaccount/namespace 中 。 
在 pod 中 ， 连 接 到 API 的 推荐 方法 是 : 


e 将 kubectl proxy 作为 pod 中 的 一 个 容器 来 运行 ， 或 作为 在 容器 内 运行 的 后 
进程 。 它 将 Kubernetes API 代理 到 Me 的 本 地 主机 接口 ， 以 便 其 他 任何 bed 
中 的 容器 内 的 进程 都 可 以 访问 它 。 请 参阅 在 pod 中 使 用 kubectl proxy 的 示 


例 o 


e 使 用 Go 客户 端 库 ， 并 使 用 rest.InClusterConfig() 和 
kubernetes.NewForConfig() 函数 创建 一 个 客户 端 。 


他 们 处 理 对 apiserver 的 定位 和 认证 。 示 例 


在 以 上 的 几 种 情况 下 ， 都 需要 使 用 pod 的 凭据 与 apiserver 进行 安全 通信 。 


访问 集群 中 运行 的 service 


上 一 节 是 关于 连接 到 kubernetes API server。 这 一 节 是 关于 连接 到 kubernetes 集 
群 中 运行 的 service。 在 Kubernetes 中 ，node、pod 和 services 都 有 它们 自己 的 
IP。 很 多 情况 下 ， 集 群 中 node 的 IP ` Pod 的 IP ` service 的 IP 都 是 不 可 路 由 的 ， 
因此 在 集群 外 面 的 机 器 就 无 法 访问 到 它们 ， 例 如 从 您 自己 的 笔记 本 电脑 。 


连接 的 方式 
您 可 以 选择 以 下 几 种 方式 从 集群 外 部 连接 到 node、pod 和 service : 


e 通过 public IP 访 问 service。 

o 使 用 NodePort 和 LoadBalancer 类 型 的 service， 以 使 service fé% 
在 集群 外 部 被 访问 到 。 请 查看 service 和 kubectl expose 文档 。 

o 根据 您 的 群集 环境 ， 这 可 能 会 将 服务 暴露 给 您 的 公司 网 络 ， 或 者 可 能 会 将 
其 暴露 在 互联 网 上 。 想 想 暴 露 的 服务 是 否 安全 。 它 是 否 自己 进行 身份 验 
E? 

o 将 pod 放 在 服务 后 面 。 要 从 一 组 副本 (例如 为 了 调试 ) 访问 一 个 特定 的 
pod， 请 在 pod 上 放置 一 个 唯一 的 label， 并 创建 一 个 选择 该 label 的 新 服 
x3 

o 在 大 多 数 情况 下 ， 应 用 程序 开发 人 员 不 需要 通过 node IP 直接 访问 节点 。 

e 通过 Proxy 规则 访问 service ` node ` pod ° 

o 在 访问 远程 服务 之 前 ， 请 执行 apiserver 认证 和 授权 。 如 果 服 务 不 够 安 
全 ， 无 法 暴露 给 互联 网 ， 或 者 为 了 访问 节点 IP 上 的 端口 或 进行 调试 ， 请 
使 用 这 种 方式 。 

o 代理 可 能 会 导致 某 些 Web 应 用 程序 出 现 问题 。 

o 仅 适 用 于 HTTP/HTTPS ° 

o 见 此 描述 。 


ee anode od 
o 运行 一 个 pod， 然 后 使 用 kubectl exec 命令 连接 到 shell » AX shell 中 连 
接 到 其 他 node ` pod 和 service ° 
o 有 些 集群 可 能 允许 ssh 到 集群 上 的 某 个 节点 。 从 那个 节点 您 可 以 访问 到 集 
群 中 的 服务 。 这 是 一 个 非 标准 的 方法 ， 它 可 能 将 在 某 些 集群 上 奏效 ， 而 在 
某 些 集群 不 行 。 这 些 节点 上 可 能 安装 了 浏览 器 和 其 他 工具 也 可 能 没有 。 群 
集 DNS 可 能 无 法 正常 工作 。 


访问 内 置 服务 


常 集群 内 会 有 几 个 在 kube-system 中 局 动 的 服务 。 使 用 kubectl cluster- 
info 命令 获取 该 列表 : 


$ kubectl cluster-info 


Kubernetes master is running at https://104.197.5.247 

elasticsearch-logging is running at https://104.197.5.247/api/ 
vi/namespaces/kube-system/services/elasticsearch-logging/proxy 

kibana-logging is running at https://104.197.5.247/api/vi/name 
spaces/kube-system/services/kibana-logging/proxy 

kube-dns is running at https://104.197.5.247/api/vi/namespaces 
/ kube-system/services/kube-dns/proxy 

grafana is running at https://104.197.5.247/api/vi/namespaces/ 
kube-system/services/monitoring-grafana/proxy 

heapster is running at https://104.197.5.247/api/vi/namespaces 
/kube-system/services/monitoring-heapster/proxy 


这 显示 了 访问 每 个 服务 的 代理 URL。 


例如 ， 此 集群 启用 了 集群 级 日 志 记 录 (使 用 Elasticsearch) ， 如 果 传 入 合适 的 赁 
据 ， 可 以 在 该 地 址 https://104.197.5.247/api/vi/namespaces/kube- 
system/services/elasticsearch-logging/proxy/ 访问 到 ， 或 通过 kubectl 4X 
理 ， 例 如 : http://localhost :8080/api/vi/namespaces/kube- 
system/services/elasticsearch-logging/proxy/ ° 


(有 关 如 何 传递 凭据 和 使 用 kubectl 代理 ， 请 参阅 上 文 ) 


手动 构建 apiserver 代理 URL 


如 上 所 述 ， 您 可 以 使 用 kubectl cluster-info 命令 来 检索 服务 的 代理 URL ° 
要 创建 包含 服务 端点 、 后 级 和 参数 的 代理 URL， 您 只 需 附 加 到 服务 的 代理 URL : 


http:// kubernetes master address /api/vi/namespaces/ namespace nam 
/services/ service name[:port name] /proxy 


如 果 您 没有 指定 port 的 名 字 ， 那 么 您 不 必 在 URL 里 指定 port name » 


示例 


e 要 想 访 问 Elasticsearch 的 服务 端点 _search?q=user:kimchy ， 您 需要 使 
用 : http://104.197.5.247/api/vi/namespaces/kube- 
system/services/elasticsearch-logging/proxy/_search? 
q-user:kimchy 

e 要 想 访问 Elasticsearch 的 集群 健康 信息 _cluster/health?pretty=true * 
您 需要 使 用 : https://104.197.5.247/api/vi/namespaces/kube- 
system/services/elasticsearch-logging/proxy/ cluster/health? 
pretty-true 


"cluster name" : "kubernetes logging", 
"status" : "yellow", 

"timed out" : false, 

"number of nodes" : 1, 
"number of data nodes" : 1, 

"active primary shards" : 5, 

"active shards" : 5, 

"relocating shards" : 6, 

"initializing shards" : 0, 

"unassigned shards" : 5 


使 用 Web 浏览 器 来 访问 集群 中 运行 的 服务 
您 可 以 将 apiserver 代理 网 址 放 在 浏览 器 的 地 址 栏 中 。 然而 : 


e Web 浏览 器 通常 不 能 传递 token， 因 此 您 可 能 需要 使 用 基本 (密码 ) 认证 。 
Apiserver 可 以 配置 为 接受 基本 认证 ， 但 您 的 集群 可 能 未 配置 为 接受 基本 认 
F 

e 某 些 网 络 应 用 程序 可 能 无 法 正常 工作 ， 特 别 是 那些 在 不 知道 代理 路 径 前 缓 的 情 
况 下 构造 URL 的 客户 端 JavaScript 。 


请 求 重 定向 


重 定 向 功能 已 被 弃 用 和 删除 。 请 改 用 代理 (MFR) 。 


多 种 代理 
在 使 用 kubernetes 的 时 候 您 可 能 会 遇 到 许多 种 不 同 的 代理 : 


1. kubectl 代理 : 
o 在 用 户 桌 面 或 pod 中 运行 
o 从 localhost 地 址 到 Kubernetes apiserver 的 代理 
o 客户 端 到 代理 使 用 HTTP 
o apiserver 的 代理 使 用 HTTPS 
o 定位 apiserver 
o 添加 身份 验证 header 
2. apiserver 代理 : 
o 将 一 个 堡垒 机 作为 apiserver 
o 将 群集 之 外 的 用 户 连接 到 群集 IP， 和 否则 可 能 无 法 访问 
o 在 apiserver 进程 中 运行 
o 客户 端 到 代理 使 用 HTTPS (或 http， 如 果 apiserver 如 此 配置 ) 
o 根据 代理 目标 的 可 用 信息 由 代理 选择 使 用 HTTP 或 HTTPS 
o 可 用 于 访问 node、pod 或 service 
o 用 于 访问 service 时 进行 负载 均衡 
3. kube 代理 : 
o 在 每 个 节点 上 运行 
o 代理 UDP 和 TCP 
o 不 支持 HTTP 
o 提供 负载 均衡 
o 只 是 用 来 访问 service 
4. apiserver 前 面 的 代理 /负载 均衡 器 : 
o 存在 和 实现 因 群 集 而 异 〈 例 如 nginx) 
o 位 于 所 有 客户 端 和 一 个 或 多 个 apiserver Z Ñ 
o 作为 负载 均衡 器 ， 如 果 有 多 个 apiserver 
5. 外 部 服务 的 云 负载 均衡 器 : 
o 由 一 些 云 提供 商 提供 (例如 AWS ELB > Google Cloud Load Balancer) 
o 当 Kubernetes service 类 型 为 LoadBalancer 时 ， 会 自动 创建 
o 仅 使 用 UDP/TCP 
o 实施 方式 因 云 提供 商 而 异 


Copyright © jimmysong.io 2017-2018 all right reserved * powered by 
GitbookUpdated at 2018-05-09 14:15:47 


使 用 kubeconfig 文件 配置 跨 集 群 认证 


Kubernetes 的 认证 方式 对 于 不 同 的 人 来 说 可 能 有 所 不 同 。 


e 运行 kubelet 可 能 有 一 种 认证 方式 ( 即 证 书 ) ° 

e 用 户 可 能 有 不 同 的 认证 方式 ( 即 令 牌 ) o 

e 管理 员 可 能 具有 他 们 为 个 人 用 户 提供 的 证 书 列表 。 

e 我 们 可 能 有 多 个 集群 ， 并 希望 在 同 全 部 定 》 这 样 用 户 就 能 使 
用 自己 的 证 书 并 重用 相同 的 全 局 配置 。 








所 以 为 了 能 够 让 用 户 轻 松 地 在 多 个 集群 之 间 切 换 ， 对 于 多 个 用 户 的 情况 下 ， 我 们 将 
其 定义 在 了 一 个 kubeconfig 文件 中 。 


此 文件 包含 一 系列 与 昵称 相关 联 的 身份 验证 机 制 和 集群 连接 信息 。 它 还 引入 了 一 个 
(用 户 ) 认证 信息 元 组 和 一 个 被 称 为 上 下 文 的 与 昵称 相关 联 的 集群 连接 信息 的 概 


o 


果 明 确 指 定 ， 则 允许 使 用 多 个 kubeconfig 文件 。 在 运行 时 ， 它 们 与 命令 行 中 指定 
的 覆盖 选项 一 起 加 载 并 合并 《参见 下 面 的 规则 ) e 


相关 讨论 
http://issue.k8s.io/1755 
Kubeconfig 文件 的 组 成 


Kubeconifg 文件 示例 


current-context: federal-context 
apiVersion: vi 
clusters: 
- cluster: 
api-version: vi 
server: http://cow.org:8080 
name: cow-cluster 
- cluster: 
certificate-authority: path/to/my/cafile 
server: https://horse.org:4443 
name: horse-cluster 
- cluster: 
insecure-skip-tls-verify: true 
server: https://pig.org:443 
name: pig-cluster 
contexts: 
- context: 
cluster: horse-cluster 
namespace: chisel-ns 
user: green-user 
name: federal-context 
- context: 
cluster: pig-cluster 
namespace: saw-ns 
user: black-user 
name: queen-anne-context 
kind: Config 
preferences: 
colors: true 
users: 
- name: blue-user 
user: 
token: blue-token 
- name: green-user 
user: 
client-certificate: path/to/my/client/cert 
client-key: path/to/my/client/key 


各 个 组 件 的 拆 解 / 释 意 


Cluster 


clusters: 
- cluster: 
certificate-authority: path/to/my/cafile 
server: https://horse.org: 4443 
name: horse-cluster 
- cluster: 
insecure-skip-tls-verify: true 
server: https://pig.org: 443 
name: pig-cluster 


cluster 中 包含 kubernetes 集群 的 端点 数据 ， 包 括 kubernetes apiserver 的 完 
整 ur| 以 及 集群 的 证 书 颁 发 机 构 或 者 当 集群 的 服务 证 书 未 被 系统 信任 的 证 书 颁 发 机 


构 签名 时 ， 设 置 insecure-skip-tls-verify: true ° 


cluster 的 名 称 (上 昵称 ) 作为 该 kubeconfig 文件 中 的 集群 字典 的 key。 您 可 以 
使 用 kubectl config set-cluster 添加 或 修改 cluster 条 目 。 


user 


users: 
- name: blue-user 
user: 
token: blue-token 
- name: green-user 
user: 
client-certificate: path/to/my/client/cert 
client-key: path/to/my/client/key 


user 定义 用 于 向 kubernetes $R st (3p 0) 2 dE 83 P 39 EVE o 4E Ja R/S H 
kubeconfig 之 后 user 将 有 一 个 名 称 (昵称) 作为 用 户 条 目 列 表 中 的 keye T 
用 和 凭证 有 client-certificate ^ client-key ^ token 和 

username/password 。 username/password 和 token 是 二 者 只 能 选择 一 
A * 42 client-certificate 和 client-key 可 以 分 别 与 它们 组 合 。 


您 可 以 使 用 kubectl config set-credentials 添加 或 者 修改 user 条 目 。 


context 


contexts: 
- context: 
cluster: horse-cluster 
namespace: chisel-ns 
user: green-user 
name: federal-context 


context 定义 了 一 个 命名 的 cluster ^ user ^ namespace 元 组 ， 用 于 使 
用 提供 的 认证 信息 和 命名 空间 将 请 求 发送 到 指定 的 集群 。 三 个 都 是 可 选 的 ; 仅 使 用 
cluster ^ user ^ namespace eode) ， A8 X none 未 指定 的 值 
或 在 加 载 的 kubeconfig 中 没有 相应 条 目的 命名 值 ( 例 如， 如 果 为 上 述 kubeconfig 
文件 指定 了 pink-user 的 上 下 文 ) 将 被 蔡 换 为 默认 值 。 有 关 和 覆盖 /合并 行为 ， 请 
参阅 下 面 的 加 载 和 合并 规则 。 


您 可 以 使 用 kubectl config set-context 添加 或 修改 上 下 文 条 目 。 
current-context 


current-context: federal-context 


current-context is the nickname or 'key' for the cluster,user,namespace tuple 
that kubectl will use by default when loading config from this file. You can override 
any of the values in kubectl from the commandline, by passing -- 
context=CONTEXT , --cluster=CLUSTER , --user-USER ,and/or -- 
namespace=NAMESPACE respectively. You can change the current-context 


with kubectl config use-context 


current-context 是 昵称 或 者 说 是 作为 cluster ^ user ^ namespace 元 
组 的 "key* > 3 kubectl 从 该 Mii bn 的 时 候 会 被 默认 使 用 。 您 可 以 在 
kubectl 命令 行 里 覆盖 这 些 值 ， 通 过 分 别传 入 —context-CONTEXT ^ -一 
cluster=CLUSTER ^ --user=USER 和 --namespace=NAMESPACE ° 


您 可 以 使 用 kubectl config use-context 更 改 current-context ° 


apiVersion: v1 

kind: Config 

preferences: 
colors: true 


杂项 
apiVersion 和 kind 标识 客户 端 解析 器 的 版 本 和 模式 ， 不 应 手动 编辑 。 


preferences 指定 可 选 (和 当前 未 使 用 ) 的 kubectl 首选 项 。 


查看 kubeconfig 文件 


kubectl config view 命令 可 以 展示 当前 的 kubeconfig 设置 。 默 认 将 为 您 展示 
所 有 的 kubeconfig 设置 ; 您 可 以 通过 传 入 -minify 参数 ， 将 视图 过 滤 到 与 
current-context 有 关 的 配额 设置 。 有 关 其 他 选项 ， 请 参阅 kubectl config 


view ° 


构建 您 自己 的 kubeconfig 文件 


您 可 以 使 用 上 文 示例 kubeconfig 文件 作为 


注意 : 如 果 您 是 通过 kube-up.sh 脚本 部 署 的 kubernetes 集群 ， 不 需要 自己 创 
建 kubeconfig 文件 一 一 该 脚本 已 经 为 您 创建 过 了 。 





{:.note} 


4 api server 启动 的 时 候 使 用 了 —token-auth-file-tokens.csv HH > Eat 
文件 将 会 与 API server 相关 联 ， tokens.csv 文件 看 起 来 会 像 这 个 样子 : 


blue-user,blue-user,1 
mister-red,mister-red,2 


注意 : 启动 API server 时 有 很 多 可 用 选项 。 请 您 一 定 要 确保 理解 您 使 用 的 选项 。 


上 述 示例 kubeconfig 文件 提供 了 green-user 的 客户 端 凭证。 因为 用 户 的 
current-user Æ green-user ， 任 何 该 API server 的 客户 端 使 用 该 示例 
kubeconfig 文件 时 都 可 以 成 功 登 录 。 同 样 ， 我 们 可 以 通过 修改 current- 
context 的 值 以 blue-user 的 身份 操作 。 


在 上 面 的 示例 中 ， green-user 通过 提供 凭据 登录 ， blue-user 使 用 的 是 
token。 使 用 kubectl config set-credentials 指定 登录 信息 。 想 了 解 更 多 信 
息 ， 请 访问 "示例 文件 相关 操作 命令 "。 


加 载 和 合并 规则 


加 载 和 合并 kubeconfig 文件 的 规则 很 简单 ， 但 有 很 多 。 最 终 的 配置 按照 以 下 顺序 构 
E 


1. 从 磁盘 中 获取 kubeconfig。 这 将 通过 以 下 层次 结构 和 合并 规则 完成 : 


如 果 设 置 了 CommandLineLocation  ( kubeconfig 命令 行 参数 的 值 ) > 
将 会 只 使 用 该 文件 ， 而 不 会 进行 合并 。 该 参数 在 一 条 命令 中 只 允许 指定 一 次 。 


或 者 ， 如 果 设 置 了 EnvVarLocation ( $KUBECONFIG 的 值 ) ， 其 将 会 被 作 
为 应 合并 的 文件 列表 ， 并 根据 以 下 规则 合并 文件 。 空 文件 名 被 忽略 。 非 串 行内 
容 的 文件 将 产生 错误 。 设 置 特定 值 或 map key 的 第 一 个 文件 将 优先 使 用 ， 并 且 
值 或 map key 也 永远 不 会 更 改 。 这 意味 着 设置 CurrentContext 的 第 一 个 文件 
将 保留 其 上 下 文 。 这 也 意味 着 如 果 两 个 文件 同时 指定 一 个 red-user ， 那 么 
将 只 使 用 第 一 个 文件 中 的 red-user 的 值 。 即 使 第 二 个 文件 的 red-user 
中 有 非 冲 突 条 目 也 被 丢弃 。 


另外 ， 使 用 Home 目录 位 置 ( -/.kube/config ) 将 不 会 合并 。 


2. 根据 此 链 中 的 第 一 个 命中 确定 要 使 用 的 上 下 文 


i 命令 行 参数 一 一 context 命令 行 选项 的 值 
i, 来自 合 并 后 的 kubeconfig 文件 的 current-context 
iii， 在 这 个 阶段 允许 空 


3. 确定 要 使 用 的 群集 信息 和 用 户 。 此 时 ， 我 们 可 能 有 也 可 能 没有 上 下 文 。 他 们 是 
基于 这 个 链 中 的 第 一 次 命中 。 (运行 两 次 ， 一 次 为 用 户 ， 一 次 为 集群 ) 





i 命令 行 参数 user 指定 用 户 ，cluster 指定 集群 名 称 
ij， 如 果 上 下 文 存在 ， 则 使 用 上 下 文 的 值 
iii, A È 
4. 确定 要 使 用 的 实际 群集 信息 。 此 时 ， 我 们 可 能 有 也 可 能 没有 集群 信息 。 根 据 链 
条 构建 每 个 集群 信息 (第 一 次 命中 胜出 ) 


j， 命 令 行 参 数 一 server ， api-version ， certificate- 
authority 和 insecure-skip-tls-verify 
ji， 如 果 存 在 集群 信息 ， 并 且 存 在 该 属性 的 值 ， 请 使 用 它 。 
ji， 如 果 没 有 服务 器 位 置 ， 则 产生 错误 。 
5. 确定 要 使 用 的 实际 用 户 信息 。 用 户 使 用 与 集群 信息 相同 的 规则 构建 ， 除 非 ， 您 
的 每 个 用 户 只 能 使 用 一 种 认证 技术 。 


ij， 负载 优先 级 为 1) 命令 行 标志 2) KA kubeconfig 的 用 户 字段 
ii. 命令 行 标志 是 : client-certificate ^ client- 
key 、 username 、 password 和 token 
iii， 如 果 有 两 种 冲突 的 技术 ， 则 失败 。 
6. 对 于 任何 仍然 缺少 的 信息 ， 将 使 用 默认 值 ， 并 可 能 会 提示 验证 信息 


7. Kubeconfig 文件 中 的 所 有 文件 引用 都 相对 于 kubeconfig 文件 本 身 的 位 置 进行 
解析 。 当 命令 行 上 显示 文件 引用 时 ， 它 们 将 相对 于 当前 工作 目录 进行 解析 。 当 
路 径 保存 在 -/.kube/config 中 时 ， 相 对 路 径 使 用 相对 存储 ， 绝 对 路 径 使 用 
绝对 存储 。 


Kubeconfig 文件 中 的 任何 路 径 都 相对 于 kubeconfig 文件 本 身 的 位 置 进 行 解析 。 


使 用 kubectl config <subcommand> 操作 
kubeconfig 


kubectl config 有 一 些 列 的 子 命令 可 以 帮助 我 们 更 方便 的 操作 kubeconfig 文 
件 。 


请 参阅 kubectl/kubectl config » 


Example 


$ kubectl config set-credentials myself --username-admin --passw 
ord-secret 

$ kubectl config set-cluster local-server --server-http://localh 
ost:8080 

$ kubectl config set-context default-context --cluster-local-ser 
ver --user=myself 

$ kubectl config use-context default-context 

$ kubectl config set contexts.default-context.namespace the-righ 
t-prefix 

$ kubectl config view 


产生 如 下 输出 : 


apiVersion: v1 
clusters: 
- cluster: 
server: http://localhost :8080 
name: local-server 
contexts: 
- context: 
cluster: local-server 
namespace: the-right-prefix 
user: myself 
name: default-context 
current-context: default-context 
kind: Config 
preferences: {} 
users: 
- name: myself 
user: 
password: secret 
username: admin 


Kubeconfig 文件 会 像 这 样子 : 


apiVersion: vi 
clusters: 
- cluster: 
server: http://localhost :8080 
name: local-server 
contexts: 
- context: 
cluster: local-server 
namespace: the-right-prefix 
user: myself 
name: default-context 
current-context: default-context 
kind: Config 
preferences: {} 
users: 
- name: myself 
user: 
password: secret 
username: admin 


示例 文件 相关 操作 命令 


$ kubectl config set preferences.colors true 

$ kubectl config set-cluster cow-cluster --server=http://cow.org 
:8080 --api-version=v1 

kubectl config set-cluster horse-cluster --server=https://hors 
.Org:4443 --certificate-authority-path/to/my/cafile 

kubectl config set-cluster pig-cluster --server=https://pig.or 
:443 --insecure-skip-tls-verify-true 

kubectl config set-credentials blue-user --token=blue-token 
kubectl config set-credentials green-user --client-certificate 
-path/to/my/client/cert --client-key-path/to/my/client/key 

$ kubectl config set-context queen-anne-context --cluster-pig-cl 
uster --user-black-user --namespace-saw-ns 

$ kubectl config set-context federal-context --cluster-horse-clu 
ster --user=green-user --namespace=chisel-ns 

$ kubectl config use-context federal-context 


FAO 6$ 0 HF 


最 后 将 它们 捆绑 在 一 起 
所 以 ， 将 这 一 切 绑 在 一 起 ， 快 速 创 建 自 己 的 kubeconfig 文件 : 


e 仔细 看 一 下 ， 了 解 您 的 api-server 的 启动 方式 : 在 设计 kubeconfig 文件 以 方便 
身份 验证 之 前 ， 您 需要 知道 您 自己 的 安全 要 求 和 策略 。 

o 将 上 面 的 代码 段 蔡 换 为 您 的 集群 的 api-server 端点 的 信息 。 

e 确保 您 的 api-server 至 少 能 够 以 提供 一 个 用 户 ( 即 green-user ) 凭据 的 方 
式 启动 。 当然 您 必须 查看 api-server 文档 ， 以 了 解 当 前 关于 身份 验证 细节 方面 
的 最 新 技术 。 


Copyright © jimmysong.io 2017-2018 all right reserved * powered by 
GitbookUpdated at 2018-05-09 14:15:47 


通过 端口 转发 访问 集群 中 的 应 用 程序 


本 页 向 您 展示 如 何 使 用 kubectl port-forward 命令 连接 到 运行 在 Kubernetes 
集群 中 的 Redis 服务 器 。 这 种 类 型 的 连接 对 于 数据 库 调 试 很 有 帮助 。 


创建 一 个 Pod 来 运行 Redis 服务 器 
1. 创建 一 个 Pod: 


kubectl create -f https://k8s.io/docs/tasks/access-applicati 
on-cluster/redis-master.yaml 


命令 运行 成 功 后 将 有 以 下 输出 验证 该 Pod 是 否 已 经 创建 : 
pod "redis-master" created 
2. 检查 Pod 是 否 正 在 运行 且 处 于 就 绪 状 态 : 
kubectl get pods 
4 Pod 就 绪 ， 输 出 显示 Running 的 状态 : 


NAME READY STATUS RESTARTS AGE 
redis-master 2/2 Running 0 41s 


3. 验证 Redis 服务 器 是 否 已 在 Pod 中 运行 ， 并 监听 6379 端口 : 


kubectl get pods redis-master --template='{{(index (index .s 
pec.containers 0).ports ©).containerPort}}{{"\n"}}' 


端口 输出 如 下 


6379 


将 本 地 端口 转发 到 Pod 中 的 端口 
1. 将 本 地 工作 站 上 的 6379 端口 转发 到 redis-master pod 的 6379 端口 : 
kubectl port-forward redis-master 6379:6379 
MERAT: 


I0710 14:43:38.274550 3655 portforward.go:225] Forwardin 
g from 127.0.0.1:6379 -> 6379 

I0710 14:43:38.274797 3655 portforward.go:225] Forwardin 
g from [::1]:6379 -> 6379 


2. 启动 Redis #447 d 
redis-cli 
3. 在 Redis 命令 行 提 示 符 下 ， 输 入 ping 命令 : 


127.0.0.1:6379>ping 


Ping 请 求 成 功 返回 PONG ° 


讨论 
创建 连接 ， 将 本 地 的 6379 端口 转发 到 运行 在 Pod 中 的 Redis 服务 器 的 6379 端 
口 。 有 了 这 个 连接 您 就 可 以 在 本 地 工作 站 中 调试 运行 在 Pod 中 的 数据 库 。 
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使 用 service 访问 群集 中 的 应 用 程序 


本 文 向 您 展示 如 何 创建 Kubernetes Service 对 象 ， n 客户 端 可 以 使 用 它 来 访问 集 
群 中 运行 的 应 用 程序 。 该 Service 可 以 为 具有 两 个 运行 实例 的 应 用 程序 提供 负载 均 
衡 。 


目的 


e 运行 Hello World 应 用 程序 的 两 个 实例 。 
e 创建 一 个 暴露 node 节点 端口 的 Service 对 象 。 
使 用 Service 对 象 访问 正在 运行 的 应 用 程序 。 


为 在 两 个 pod 中 运行 的 应 用 程序 创建 service 
1. 在 集群 中 运行 Hello World 应 用 程序 : 


kubectl run hello-world --replicas=2 --labels="run=load-bala 
ncer-example" --image-gcr.io/google-samples/node-hello:1.0 
--port=8080 


上 述 命令 创建 一 个 Deployment 对 象 和 一 个 相关 联 的 ReplicaSet 对 象 。 该 
ReplicaSet 有 两 个 Pod， 每 个 Pod 中 都 运行 一 个 Hello World 应 用 程序 。 


2. 显示 关于 该 Deployment 的 信息 : 


kubectl get deployments hello-world 
kubectl describe deployments hello-world 


3. 显示 ReplicaSet 的 信息 : 


kubectl get replicasets 
kubectl describe replicasets 


4. 创建 一 个 暴露 该 Deployment 的 Service 对 象 : 


kubectl expose deployment hello-world --type=NodePort --name 
=example-service 


5. 显示 该 Service 的 信息 : 


kubectl describe services example-service 


输出 类 似 于 : 
Name : example-service 
Namespace: default 
Labels: run-load-balancer-example 
Selector: run-load-balancer-example 
Type: NodePort 
IP: 10.32.0.16 
Port: «unset» 8080/TCP 
NodePort: «unset» 31496/TCP 
Endpoints: 10.200.1.4:8080,10.200.2.5:8080 
Session Affinity: None 
No events. 


记 下 服务 的 NodePort 值 。 例 如 ， 在 前 面 的 输出 中 ，NodePort 144 31496 » 


6. 列 出 运行 Hello World 应 用 程序 的 Pod : 


kubectl get pods --selector="run=load-balancer-example" --ou 
tput=wide 

输出 类 似 于 : 
NAME READY STATUS cea iP 

NODE 

hello-world-2895499144-bsbk5 1/1 Running ... 10.20 
0.1.4  worker1 
hello-world-2895499144-mipwt 1/1 Running ... 10.20 


0.2.5 worker2 


7. 获取 正在 运行 Hello World 应 用 程序 的 Pod 的 其 中 一 个 节点 的 public IP 地 
址 。 如 何 得 T 文 个 地 址 取决 于 您 的 集群 设置 。 例 如 ， 如 果 您 使 用 Minikube > "T 
以 通过 运行 kubectl cluster-info 查看 节点 地 址 。 如 果 您 是 使 用 Google 


Compute Engine 实例 ， 可 以 使 用 gcloud compute instances list 命令 
查看 您 的 公共 地 址 节点 。 


8. 在 您 选择 的 节点 上 ， 在 您 的 节点 端口 上 例如 创建 允许 TCP 流量 的 防火 墙 规 
则 ， 如 果 您 的 服务 NodePort 值 为 31568， 创 建 防火 墙 规 则 ， 允 许 端 口 31568 
上 的 TCP 流 量 。 


9. 使 用 节点 地 址 和 节点 端口 访问 Hello World 应 用 程序 : 


curl http://<public-node-ip>:<node-port> 


其 中 <public-node-ip> 是 您 节点 的 public IP 地 址 ， 而 <node-port> 是 
您 服务 的 NodePort 值 。 


对 成 功 请 求 的 响应 是 一 个 hello 消息 : 


Hello Kubernetes! 


使 用 Service 配置 文件 


作为 使 用 kubectl expose 的 替代 方法 ， 您 可 以 使 用 service 配置 文件 来 创建 
Service。 


要 删除 Service， 输 入 以 下 命令 : 


kubectl delete services example-service 


删除 Deployment ` ReplicaSet #736 i£ 477€ Pod 中 的 Hello World 应 用 程序 ， 输 入 
以 下 命令 : 


kubectl delete deployment hello-world 


了 解 更 多 关于 使 用 service 连接 应 用 程序 。 
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使 用 service 访 问 群 集中 的 应 用 程序 


578 


从 外 部 访问 Kubernetes 中 的 Pod 


前 面 几 节 讲 到 如 何 访 问 kubneretes 集 群 ， 本 文 主要 讲解 访问 kubenretes 中 的 Pod 和 
Serivce 的 集中 方式 ， 包 括 如 下 几 种 : 


e hostNetwork 
e hostPort 

e NodePort 

e LoadBalancer 
e Ingress 


说 是 暴露 Pod 其 实 跟 暴 露 Service 是 一 回 事 ， 因 为 Pod 就 是 Service 的 backend ° 


hostNetwork: true 
这 是 一 种 直接 定义 Pod 网 络 的 方式 。 


如 果 在 Pod 中 使 用 hostNotwork:true 配置 的 话 ， 在 这 种 pod 中 运行 的 应 用 程序 可 
以 直接 看 到 pod 局 动 的 主机 的 网 络 接口 。 在 主机 的 所 有 网 络 接口 上 都 可 以 访问 到 该 
应 用 程序 。 以 下 是 使 用 主机 网 络 的 pod 的 示例 定义 : 


apiVersion: vi 
kind: Pod 
metadata: 
name: influxdb 
spec: 
hostNetwork: true 
containers: 
- name: influxdb 
image: influxdb 


部 署 该 Pod : 
$ kubectl create -f influxdb-hostnetwork.yml 


访问 该 pod 所 在 主机 的 8086 端 口 : 


curl -v http://$POD IP:8086/ping 


J4 A 81204 No Content 的 204 返 回 码 ， 说 明 可 以 正常 访问 。 


注意 每 次 启动 这 个 Pod 的 时 候 都 可 能 被 调度 到 不 同 的 节点 上 ， 所 有 外 部 访问 Pod 的 
IP 也 是 变化 的 ， 而 且 调 度 Pod 的 时 候 还 需要 考虑 是 否 与 簿 主机 上 的 端口 冲突 ， 因 此 
一 般 情 况 下 除非 您 知道 需要 某 个 特定 应 用 占用 特定 宿主 机 上 的 特定 端口 时 才 使 

用 hostNetwork: true 的 方式 。 


这 种 Pod 的 网 络 模式 有 一 个 用 处 就 是 可 以 将 网 络 插件 包装 在 Pod 中 然后 部 署 在 每 个 
宿主 机 上 ， 这 样 该 Pod 就 可 以 控制 该 宿主 机 上 的 所 有 网 络 。 


hostPort 


这 是 一 种 直接 定义 Pod 网 络 的 方式 。 


hostPort 是 直接 将 容器 的 端口 与 所 调度 的 节点 上 的 端口 路 由 ， 这 样 用 户 就 可 以 通 
过 宿主 机 的 |P 加 上 来 访问 Pod 了 ， 如 :。 


apiVersion: v1 
kind: Pod 
metadata: 
name: influxdb 
spec: 
containers: 

- name: influxdb 
image: influxdb 
ports: 

- containerPort: 8086 
hostPort: 8086 


这 样 做 有 个 缺点 ， 因 为 Pod 重 新 调度 的 时 候 该 Pod 被 调度 到 的 宿主 机 可 能 会 变动 ， 
这 样 就 变化 了 ， 用 户 必 须 自己 维护 一 个 Pod 与 所 在 宿主 机 的 对 应 关系 。 


这 种 网 络 方式 可 以 用 来 做 nginx Ingress controller。 外 部 流量 都 需要 通 
kubenretes node 节 点 的 80 和 443 端 口 。 


NodePort 


NodePort 在 kubenretes 里 是 一 个 广泛 应 用 的 服务 暴露 方式 。 Kubernetes ¥ 49 
service 默认 情况 下 都 是 使 用 的 clusterIP 这 种 类 型 ， 这 样 的 service 会 产生 一 个 
ClusterIP， 这 个 IP 只 能 在 集群 内 部 访问 ， 要 想 让 外 部 能 够 直接 访问 service， 需 要 将 
service type 修改 为 nodePort 。 


apiVersion: vi 
kind: Pod 
metadata: 
name: influxdb 
labels: 
name: influxdb 
spec: 
containers: 

- name: influxdb 
image: influxdb 
ports: 

- containerPort: 8086 


同时 还 可 以 给 service 指 定 一 个 nodePort 44° 36, 8]:€ 30000-32767 > 3X 4- 4& J£ API 
server 的 配置 文件 中 ， 用 --service-node-port-range 定义 。 


kind: Service 
apiVersion: vi 
metadata: 
name: influxdb 
spec: 
type: NodePort 
ports: 
- port: 8086 
nodePort: 30000 
selector: 
name: influxdb 


集群 外 就 可 以 使 用 kubernetes 任 意 一 个 节点 的 IP 加 上 30000 端 口 访问 该 服务 了 。 
kube-proxy 会 自动 将 流量 以 round-robin 的 方式 转发 给 该 service 的 每 一 个 pod 。 


这 种 服务 暴露 方式 ， 无 法 让 你 指定 自己 想 要 的 应 用 常用 端口 ， 不 过 可 以 在 集群 上 再 
部 署 一 个 反 向 代理 作为 流量 入 口 。 
LoadBalancer 


LoadBalancer 只 能 在 service 上 定义 。 这 是 公有 云 提 供 的 负载 均衡 器 ， 如 AWS、 
Azure、CloudStack、GCE 等 。 


kind: Service 
apiVersion: vi 


metadata: 
name: influxdb 
spec: 
type: LoadBalancer 
ports: 
- port: 8086 
selector: 


name: influxdb 


$ kubectl get svc influxdb 
NAME CLUSTER- IP EXTERNAL - IP PORT(S) AGE 
influxdb 10.97.121.42 10.13.242.236 8086:30051/TCP 39s 


内 部 可 以 使 用 ClusterIP 加 端口 来 访问 服务 ， 如 19.97.121.42:8086 ° 
外 部 可 以 用 以 下 两 种 方式 访问 该 服务 : 


e 使 用 任 一 节点 的 IJP 加 30051 端 口 访 问 该 服务 
e 使 用 EXTERNAL-IP 来 访问 ， 这 是 一 个 VIP， 是 云 供 应 商 提供 的 负载 均衡 器 
IP， 如 10.13.242.236:8086 ° 


Ingress 


Ingress 是 自 kubernetes1.1 版 本 后 引入 的 资源 类 型 。 必 须要 部 署 Ingress 
controller 才 能 创建 Ingress 资 源 ，lngress controller 是 以 一 种 插件 的 形式 提供 。 
Ingress controller 是 部 署 在 Kubernetes 之 上 的 Docker 容 器 。 它 的 Docker 镜 像 包 含 一 
个 像 nginx 或 HAProxy 的 负载 均衡 器 和 一 个 控制 器 守护 进程 。 控 制 器 守护 程序 从 
Kubernetes 接 收 所 需 的 Ingress 配 置 。 它 会 生成 一 个 nginx 或 HAProxy 配 置 文件 ， 并 
重新 启动 负载 平衡 器 进程 以 使 更 改 生效 。 换 句 话说，|ngress controller 是 由 
Kubernetes 管 理 的 负载 均衡 器 。 

Kubernetes Ingress 提 供 了 负载 平衡 器 的 典型 特性 : HTTP 路 由 ， 粘 性 会 话 ，SSL 终 


止 ，SSL 直 通 ，TCP 和 UDP 负载 平衡 等 。 目 前 并 不 是 所 有 的 Ingress controller 都 实 
现 了 这 些 功能 ， 需 要 查看 具体 的 Ingress controller 文 档 。 


apiVersion: extensions/vibeta1 
kind: Ingress 
metadata: 
name: influxdb 
spec: 
rules: 
- host: influxdb.kube.example.com 
http: 
paths: 
- backend: 
serviceName: influxdb 
servicePort: 8086 


外 部 访问 URL http://influxdb.kube.example.com/ping 访问 该 服务 ， 入 口 就 是 80 端 
口 ， 然 后 Ingress controller 直 接 将 流量 转发 给 后 端 Pod， 不 需 再 经 过 kube-proxy 的 转 


发 ， 比 LoadBalancer 方 式 更 高 效 。 


$4 


Cx 


^N 


总 的 来 说 Ingress 是 一 个 非常 灵活 和 越 来 越 得 到 厂商 支持 的 服务 暴露 方式 ， 包 括 
Nginx、HAProxy、Traefik， 还 有 各 种 Service Mesh ， 而 其 它 服务 暴露 方式 可 以 更 
和 所 用 于 服务 调试 、 特 殊 应 用 的 部 署 。 


e Accessing Kubernetes Pods from Outside of the Cluster - alesnosek.com 
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Cabin - Kubernetes 手 机 客户 端 
cabin 是 由 bitnami 开 源 的 手机 管理 Kubernetes 集 群 的 客户 端 ， 目 前 提供 iOS 和 安 卓 版 
本 ， 代 码 开 源 在 GitHub 上 : https://bitnami.com/ 


为 了 方便 移动 办 公 ， 可 以 使 用 Cabin 这 个 kuberntes 手 机 客户 端 ， 可 以 链接 GKE 和 任 
何 Kubernetes 集 群 ， 可 以 使 用 以 下 三 种 认证 方式 : 

e 十 书 

e token 


e kubeconfig x 4} 


所 有 功能 跟 kubernetes dashboard 相 同 ， 还 可 以 支持 使 用 Helm chart 部 署 应 用 ， 可 
以 配置 自 定义 的 chart 仓 库 地 址 。 


iPhone 用 户 可 以 在 App Store 中 搜索 Cabin 即 可 找到 。 


Cabin - Kubernetes FPLR P 3% 


e PARKE v x 上 午 10:52 @ 7 9 3 709 (m )^ 
€ Search 


Cabin - Manage 
Kubernetes 
Skippbox 


XC X 4+ 





Manage kubernetes clusters 
with ease. 


https://11.12 


Namespace: All nam 


http://localhost:8080 





图 ohost-3378155678-sb 





https://101.102.103.104 
a redis-standalone-479k 


6 tiller-deploy-64255717 


https://11.12.13.14 


a kube-dns-v11-vcpom 


O kubernetes-dashboard 











Today Games Apps Updates Search 
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图 片 App Store 


可 以 很 方便 的 在 手机 上 操作 自己 的 kubernetes 集 群 ， 还 可 以 登录 到 容器 中 操作 ， 只 
要 是 kubernetes API 支 持 的 功能 ， 都 可 以 在 该 移动 客户 端 上 实现 。 


Cabin - Kubernetes > du € P 35 


all 中 国联 通 ^ 上 午 11:01 全 SALA | 


< BJ Q 


Namespace: All namespaces v 





Pods Services Nodes Deployments 


monitoring-influxdb > 
heapster » 
monitoring-grafana > 
redis-slave > 
redis-master > 
frontend > 
kubernetes-dashboard > 
kube-dns > 





Clusters Deploy Settings 
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EH - 在 手机 上 操作 Kubemetes 集 群 


更 多 详细 信息 请 参考 : https://github.com/bitnami/cabin 
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Kubernetic - —#kubenretes X @ & P š% > https://kubernetic.com/ > 44} vA TF 4$ 
性 : 


e 实时 展示 集群 状态 

e 多 集群 ， 多 个 namespace 管 理 
e 原生 kubernetes 支 持 

e 支持 使 用 chart 安 装 应 用 

e 使 用 kubeconfig 登 陆 认 证 


eoe Kubernetic - The Desktop Client for Kubernetes 


Infrastructure 
O Deployments auto-model-master-1510556211771 f Update Version + Scale Up — Scale Down Delete 


© Status # Specifications </> View ® Labels 


NAME ~ TYPE READY STATUS AGE 
eee © auto-model-master-1510556211771 Deployment @ 2/2/2/2 16d 
& auto-model-master-151055621177.. ReplicaSet e 2/2 16d 

© auto-model-master-15105562117... Pod @ 1/1 Running 16d 

@ auto-model-master-15105562117... Pod @ 1/1 Running 29s 


Controllers 


Chart Management 





图 片 - Kubernetic® P 35 


该 客户 端 支持 Mac 和 Windows 系 统 ，beta 版 本 免费 使 用 ，stable 版 本 需要 付费 。 
beta 版 本 某 些 功能 不 完善 ， 比 如 无 法 在 应 用 内 修改 ingress 配 置 ， 无 法 监控 应 用 的 状 
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Kubernator - € /& Æ #4) Kubernetes UI 


Kubernator28 £&- T Kubernetes Dashboard% 3X, > Æ% — ^ # JK. 49 Kubernetes UI > 
Dashboard 操 作 的 都 是 Kubernetes 的 底层 对 象 ， 而 Kubernator 是 直接 操作 
Kubernetes 各 个 对 象 的 YAML 文 件 。 


Kubernator 提 供 了 一 种 基于 目录 树 和 关系 拓扑 图 的 方式 来 管理 Kubernetes 的 对 象 的 
方法 ， 用 户 可 以 在 Web 上 像 通过 GitHub 的 网 页 版 一 样 操作 Kubernetes 的 对 象 ， 执 行 
修改 、 找 贝 等 操作 ， 详 细 的 使 用 方式 见 https://github.com/smpio/kubernator ° 


7X Kubernator 


Kubernator 的 安装 十 分 简单 ， 可 以 直接 使 用 kubectl 命令 来 运行 ， 它 不 依赖 任何 
其 它 组 件 。 


kubectl create ns kubernator 

kubectl -n kubernator run --image=smpio/kubernator --port=80 kub 
ernator 

kubectl -n kubernator expose deploy kubernator 

kubectl proxy 


然后 就 可 以 通过 

http://localhost:8001 /api/v1/namespaces/kubernator/services/kubernator/proxy/#& 
访问 了 。 

Catalog Jt @ ii ise 到 Kubernetes 中 资源 对 象 的 树 形 结构 ， 还 可 以 在 该 页 面 中 对 资 
源 对 象 的 配置 进行 更 改 和 操作 。 


Kubernator - 更 底层 的 Kubernetes UI 


© Kubernator v0.14.9 | API v1.8.5 x 


€ > C f |O localhost&001/api/vijnamespaces/kubernator/services/kubernator/proxy/tt/catalog LIE EE E O 9: 
e kubernator kubernator + x a 
[nonamespace: 1 1 bpiversion: extensions/vibetal | | 
2 2 kind: Deployment 
wenodst 3 3 metadata: 
brand 4 4 annotations: 
55 deployment.kubernetes.io/revision: "1" 
conduit 6 6  creationTimestamp: 2017-12-27T03:33:362 
7 7 generation: 1 
custom-metrics 8 8 labels: 
9 9 run: kubernator 
3) default 10 10 name: kubernator 
li. div 11 11 | namespace: kubernator 
12 12  resourceVersion: "41063244" 
jj. emajivoto 13 13 selfLink: /apis/extensions/vibetal/namespaces/kubernator/deployments/kubernator 
14 14 uid: b89e3673-eab6-11e7-aa47-f4e9d49fBedO 
3) kube-public 15 15 spec: 
16 16 replicas: 1 
习 kube-system 17 17 selector: 
18 18 matchLabels: 
TUDMDMOE 19 19 run: kubernator 
Deployment 20 20 strategy: 
21 21 rollingUpdate: 
* kubernator 22 22 maxSurge: 1 
23 23 maxUnavailable: 1 
Endpoints 24 24 type: RollingUpdate 
^ iabamator 25 2 template: 
26 26 metadata: 
B bye 27 27 creationTimestamp: null 
28 28 labels: 
i Pod 29 2 run: kubernator 
30 30 spect 
1 ReplicaSet 313 containers: 
323 - image: sz-pg-oam-docker-hub-001, tendc loud. com/Library/kubernator: latest 
用 Secret 33 33 imagePullPolicy: Always 
34 34 name: kubernator 
i Service 
35 35 ports: 
和 ServiceAccount 36 36 - containerPort: 80 
33 protocol: TCP 
3 spark-cluster 38 38 resources: () 
39 39 terminationMessagePath: /dev/termination-log 
3^ trip-backend-service 40 40 terminationMessagePolicy: File 
41 41 dnsPolicy: ClusterFirst 
yam-cluster 42 42 restartPolicy: Always 
43 43 schedulerName: default-scheduler 
44 44 securityContext: {} 


图 片 - Kubernator catalog i @ 


Rbac 页 面 可 以 看 到 集群 中 RBAC 关 系 及 结构 。 
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Kubernator - 更 底层 的 Kubernetes UI 


© Kubernator v0.14.9 | API v1.8.5 x 


€ Q (Y |O localhost:8001/api/v1/namespaces/kubernator/services/kubernator/proxy/#/rbac *¥ 9080 5% 








È talog Rbac 





Legend Isolated Names 


Quse @Group @ ServiceAccount @ Role @ ClusterRole RoleBinding © — ClusterRoleBinding 


'weave-scope 
system.auth-dé -fé-coniselieqptroller controller 
custom-metrics-3 


(Ver-resources ube-pyitiér; 5gybtemcoattibtlebbobtttapesigner 


@ kubernetes-dashboard-minimd, " Weave-scope custom-metrics:system:auth-delegator 


system:controllàr:daemon-set- ll sielm:controller:endpoint-controller 
\ 


\kube-system / K 
iSystem:controllekdaemon-set-cont 


bootstrap-signer 







stem:kube-proxy 


















stem:node-proxier 


system:node-proxier 
15 kubernetes-dash 
daemon-set-controller 


statefulset-controll 
@ systemi:lesder-locking-kubs ‘ontroller:statefulset-co} 
\ Stem:controller:statefulset-controller 





system:contrjlecssenicesen! i 
system:authenticated prometheus-oper; Ystem:controlier:pod émtiigeceartftaeres. 8s. io:certificatesigningrequests:selfnodeclient 


fod-garbage-collector 








system:kube-controller-manager 
Qu kube-controller-manager 


rancher-kubern esses 
Sys fei KBE Controller-manager 
d kube-system / system::leader-locking-kube-controller-m 
mi : 
ficher-kubernetes-dashboard-binding V 


system;kube-dontroller-manager 
system:leader-locking-kube-controller-manager 








\Kube-system / system::leader-locking-kube-scheduler 















prometheus 
route-controller 


19 kube-scheduler 


ingress 


job-controller 
roller 





ttl-controller 






kube-dns 


efk 












namespace- system:kube-dns 


Ystem:controller:namespace-controller istem:controller:certificate-controllly system:controller:job-controller 


controller system:controller:certificate-controller jetz 
er er hoalst' Botetrap. system:kube-dns 
SPR ode-bootstrapper 


/stem:controller:namespac; 
System:controller:tti-control 












Q view @ system:controlirdRerikegpaled-vin 
conduit-controller inx-ingress-nginx-ingress j 
riis inx-ingress-nginx-ingress gemikube-sçheduler ol Kube-system | system:c ORO GR OS 
er Scheduler | / 
Eonduit-controller inx-ingress-nginx-ingress BEST Robe scheduler 
persistent-volume-binder — default / nginx-ingress-nginx-ingress E token-cleaner 
: ~@ nginx-ingress-nginx-ingress @ devuser kube-keepalived-vip 
Ystem:controller:persistent-volume-binder 





ystem:controller;persistent- 






iresentroller:resourcequota-controller \ 


ttem:controller.resourcequota-cont replication-controller dev / devuser-admin-binding 
resourcequota-cont tem:controllerreplicdBomyatserpleristent-volume-proyisioner 


图 片 - Kubernator rbac i @ 
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在 Kubernetes 中 开发 部 署 应 用 


理论 上 只 要 可 以 使 用 主机 名 做 服务 注册 的 应 用 都 可 以 迁移 到 kubernetes 集群 上 。 
看 到 这 里 你 可 能 不 禁 要 问 ， 为 什么 使 用 IP 地 址 做 服务 注册 发 现 的 应 用 不 适合 迁移 
到 kubernetes 集群 ? 因为 这 样 的 应 用 不 适合 自动 故障 恢复 ， 因 为 目前 kubernetes 
中 不 支持 国定 Pod 的 IP 地 址 ， 当 Pod 故障 后 自动 转移 到 其 他 Node 的 时 候 该 Pod 
的 IP 地 址 也 随 之 变化 。 


将 传统 应 用 迁移 到 kubernetes 中 可 能 还 有 很 长 的 路 要 走 ， 但 是 直接 开发 Cloud 
native 应 用 ，kubernetes 就 是 最 佳 运行 时 环境 了 。 
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J | kul bernet es 的 以 H0] 7 


适用 于 kubernetes 的 应 用 开发 部 署 流 程 


本 文 讲解 了 如 何 开发 容器 化 应 用 ， 并 使 用 Wercker 持 续集 成 工具 构建 docker 镜 像 上 
传 到 docker 镜 像 仓库 中 ， 然 后 在 本 地 使 用 docker-compose 测 试 后 ， 再 使 

用 kompose 自动 生成 kubernetes 的 yaml 文 件 ， 再 将 注入 Envoy sidecar 容 器 ， 集 成 
Istio service mesh 中 的 详细 过 程 。 


整个 过 程 如 下 图 所 示 。 














How to build containerized applications 
and 
deploy them to kubernetes within Istio service mesh 





docker 


sidecar container 


https://github.com/rootsongjc/k8s-app-monitor-test 





k8s-app-monitor-test 








docker 


a 
docker 


pe yaml 










trigger > ~=/ —build 








https://github.com/rootsongjc/k8s-app-monitor-agent 


wercker 





istioctl T kubect| 一 一 一 全 EX 


source https://jimmysong.io 











EA - 流程 图 


为 了 讲解 详细 流程 ， 我 特意 写 了 用 Go 语言 开发 的 示例 程序 放 在 GitHub 中 ， 模 拟 监 
控 流 程 : 


ROR 
9 b: ) 


六 nm I 


& Jt T kubernetes 9$] & t 7 


e k8s-app-monitor-test : 生成 模拟 的 监控 数据 ， 在 接收 到 http 请 求 返 回 json 格 式 


的 metrics 信 息 


e K8s-app-monitor-agent : 获取 监控 metrics 信 息 并 绘图 ， 访 问 该 服务 将 获得 监 


控 图 表 


API 文 档 见 k8s-app-monitor-test 中 的 api.html 文件 ， 该 文档 在 API blueprint F? Æ 
义 ， 使 用 aglio 生 成 ， 打 开 后 如 图 所 示 : 


Overview 


Metrics 


Kubernetes app monitoring test 


This is a simple application to test the application monitoring in kubernetes. For the rules used as a reference 


when building this application, see The Rules of Go 


Resource Group Metrics 


List All Metric v The application only has one monitoring metric now. 


Get the specific application... 


http://localhost:3000/ 


关于 服务 发 现 


Resource Group 


METRICS COLLECTION 


The metric collection represents the status of the application. 


ca /metrics List All Metric 


Get the application's metric now. 
Example URI 


GET http://localhost:3000//metrics 
Response 200 Show 


GET SPECIFIC APPLICATION METRIC 


Get the specific application's metric. 
LE /metrics/{appname} Get the specific application metric 


Example URI 


GET http://localhost:3000//metrics/"Gateway. quota. request" 
URI Parameters Hide 


appname string (required) Example: "Gateway. quota request" 


Response 200 Show 
Response 404 Show 
Generated by aglio on 18 Jul 2017 
AA -API 


K8s-app-monitor-agent 服务 需要 访问 k8s-app-monitor-test 服务 ， 这 就 涉 
及 到 服务 发 现 的 问题 ， 我 们 在 代码 中 直接 写 死 了 要 访问 的 服务 的 内 网 DNS 地 址 
(kubedns 中 的 地 址 ， 即 k8s-app-monitor- 
test.default.svc.cluster.local ) 。 


我 们 知道 Kubernetes 在 启动 Pod 的 时 候 为 容器 注入 环境 变量 ， 这 些 环境 变量 在 所 有 
的 namespace 中 共享 (环境 变量 是 不 断 追 加 的 ， 新 启动 的 Pod 中 将 拥有 老 的 Pod 中 
所 有 的 环境 变量 ， 而 老 的 Pod 中 的 环境 变量 不 变 ) 。 但 是 既然 使 用 这 些 环境 变量 就 
已 经 可 以 访问 到 对 应 的 service， 那 么 获取 应 用 的 地 址 信息 ， 究 竟 是 使 用 变量 呢 ? 还 
是 直接 使 用 DNS 解析 来 发 现 ? 

答案 是 使 用 DNS， 详 细 说 明 见 Kubernetes 中 的 服务 发 现 与 Docker 容 器 间 的 环境 变量 
传递 源码 探究 。 


为 我 使 用 wercker 自 动 构建 ， 构 建 完 成 后 自动 打包 成 docker 镜 像 并 上 传 到 docker 
hub? (需要 现在 docker hub 中 创建 repo) 。 


构建 流程 见 : https://app.wercker.com/jimmysong/k8s-app-monitor-agent/ 


ORACLE + wercker Registry Applications (m 


EB jimmysong / k8s-app-monitor-agent e 


> Workflows LA Access <> Environment Æ Options 





Search - D View: Grouped | List c 


#da26866 add title to chart 


#e4143c3 add title Y master jay ago 


图 — v build — v deploy-dockerhub 


#3c1f5a5 first commit P master i day ago 


® — v build — v deploy-dockerhub 


图 片 - Wercker 构 建 页 面 


生成 了 如 下 两 个 docker 镜 像 : 


e jimmysong/k8s-app-monitor-test:9c935dd 
e jimmysong/k8s-app-monitor-agent:234d51c 


测 试 


在 将 服务 发 布 到 线 上 之 前 ， 我 们 可 以 先 使 用 docker-compose 在 本 地 测试 一 下 ， 这 两 
个 应 用 的 docker-compose.yaml 文件 如 下 


version: '2' 
services: 
k8s-app-monitor-agent: 
image: jimmysong/k8s-app-monitor -agent :234d51c 
container_name: monitor-agent 
depends_on: 
- k8s-app-monitor-test 
ports: 
- 8888:8888 
environment: 
- SERVICE_NAME=k8s-app-monitor-test 
k8s-app-monitor-test: 
image: jimmysong/k8s-app-monitor-test:9c935dd 
container name: monitor-test 
ports: 
- 3000:3000 


docker-compose up 


在 浏览 器 中 访问 http://localhost:8888/k8s-app-monitor-test 就 可 以 看 到 监控 页 面 。 


所 有 的 kubernetes 应 用 启动 所 用 的 yaml 配 置 文件 都 保存 在 那 两 个 GitHub 仓 库 


的 manifest.yaml 文件 中 。 也 可 以 使 用 kompose 这 个 工具 ， 可 以 将 qocker- 
compose 的 YAML 文 件 转换 成 kubernetes 规 格 的 YAML 文 件 。 


分 别 在 两 个 GitHub 目 录 下 执行 kubectl create -f manifest.yaml 即 可 启动 服 
务 。 也 可 以 直接 在 k8s-app-monitor-agent 代 码 库 的 k8s 目录 下 执行 kubectl 
apply -f kompose ° 


在 以 上 YAML 文 件 中 有 包含 了 Ingress 配 置 ， 是 为 了 将 k8s-app-monitor-agent 服 务 暴 
露 给 集群 外 部 访问 。 


A 
服务 启动 后 需要 更 新 ingress 配 置 ， 在 ingress.yaml 文 件 中 增加 以 下 几 行 : 


- host: k8s-app-monitor-agent.jimmysong.io 


http: 
paths: 
- path: /k8s-app-monitor -agent 
backend: 


serviceName: k8s-app-monitor-agent 
servicePort: 8888 


保存 后 ， 然 后 执行 kubectl replace -f ingress.yaml 即 可 刷新 ingress。 


修改 本 机 的 /etc/hosts 文件 ， 在 其 中 加 入 以 下 一 行 : 


172.20.0.119 k8s-app-monitor-agent.jimmysong.io 


当然 你 也 可 以 将 该 域名 加 入 到 内 网 的 DNS 中 ， 为 了 简单 起 见 我 使 用 hosts。 
FRA 


或 者 不 修改 已 有 的 Ingress， 而 是 为 该 队 外 暴露 的 服务 单独 创建 一 个 Ingress， 如 
Pi 


apiVersion: extensions/vibetal 
kind: Ingress 
metadata: 
name: k8s-app-monitor-agent-ingress 
annotations: 
kubernetes.io/ingress.class: "treafik" 
spec: 
rules: 
- host: k8s-app-monitor-agent.jimmysong.io 
http: 
paths: 
- path: / 
backend: 
serviceName: k8s-app-monitor-agent 
servicePort: 8888 


详 见 边缘 节点 配置 。 


集成 lstio service mesh 


上 一 步 中 我 们 生成 了 kubernetes 可 读 取 的 应 用 的 YAML 配 置 文件 ， 我 们 可 以 将 所 有 
的 YAML 配 置 和 并 到 同一 个 YAML 文 件 中 假如 文件 名 为 k8s-app-monitor-istio- 


all-in-one.yaml ， 如 果 要 将 其 集成 到 lstio service mesh， 只 需要 执行 下 面 的 命 


Ao 


kubectl apply -n default -f <(istioctl kube-inject -f k8s-app-mo 
nitor-istio-all-in-one.yaml) 


这 样 就 会 在 每 个 Pod 中 注入 一 个 sidecar 容 器 。 
人 ` 
YT LE 


如 果 您 使 用 的 是 Traefik ingress 来 暴露 的 服务 ， 那 么 在 浏览 器 中 访问 http://k8s-app- 
monitor-agent.jimmysong.io/k8s-app-monitor-agent， 可 以 看 到 如 下 的 画面 ， 每 次 
刷新 页 面 将 看 到 新 的 柱状 图 。 


适用 于 kubernetes 的 应 用 开发 部 署 流程 





~la k8s-app-monitor-agent.jimm. x 


€ ca | © k8s-app-monitor-agent jimmysong.io *| S9O0aeauR & @*: 

AppName:test-app — 

Domain:test-domain 90.86 

Host:k8s-app-monitor-test-3181994647-mnbd1 82.66 

74.46 

66.16 

57.96 

49.76 

41.56 

33.36 

25.16 

16.96 

Dal: 

— 0.46 
FailRatio FailAmount AccessAmount MaxConcurrent MinLatency AvgLatency 

图 片 - 图 表 


使 用 kubernetes-vagrant-centos-cluster 来 部 署 的 kubernetes 集 群 ， 该 应 用 集成 了 
Istio service mesh 后 可 以 通过 http://172.17.8.101:32000/k8s-app-monitor-agent 来 
访问 。 











在 对 k8s-app-monitor-agent 服 务 进行 了 N 此 访问 之 后 ， 再 访问 
http://grafana.istio.jimmysong.io T 2 Æ #] Service Mesh 的 监控 信息 。 
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Oo. ; 1$ Grafana - Istio Dashboard x Y Jimmy 


€ C ( © grafanaistio.jimmysong.io/d/1/istio-dashboard?refresh-5s&orgld-1 六 多 Om emo i 


Istio Dashboard - 


Source Ally Source Version HTTP Destination Ally TCP Destination All ~ Destination Version All ~ G istio.io 


> Row title 
v Dashboard Row 


Global Request Volume Global Success Rate (non-5xx responses) 4xxs 


| 


93.3% | | 10.010 ops 


HJ 


» Service Mesh 


Service Mesh 


Request Volume Success Rate by Service (non-5xx responses) 4xxs by Service 5xxs by Service 
20 ops ACK eeu —M——————— 0.25 ops 2.5 ops 


2.0 ops 


75.00% 0.20 ops 
| 


15 ops 
ela 50.0 0.15 ops ees 


1 
Saye 1.0 ops 


0.10 ops 


5ops 0.5 ops 
0x 0.05 ops 
22:14 22:16 Oops » 
Oops SSS istio-ingress.istio-system 22:14 22:16 
22:14 2216. k8s-app-monitor-agent.default 3 istio-ingress.istio-system 


All 200s 一 400s = k8s-app-monitor-test.default istio-ingress.istio-system k8s-app-monitor-agent.default 





图 片 - Grafana 页 面 


访问 可 以 看 到 服务 的 依赖 和 QPS 信 息 。 





[4 Tiny example 


E C € @ servicegraph.istio.jimmysong.io/dotviz 








reqs/sec: 0.749153 


istio-ingress.istio-system (unknown) 


reqs/sec: 0.742373 


k8s-app-monitor-agent.default (unknown) 


reqs/sec: 0.742373 
k8s-app-monitor-test.default (unknown) 
图 片 - servicegraph 9i dn 


访问 http://zipkin.istio.jimmysong.io 可 以 选择 查看 k8s-app-monitor-agent 应 用 
的 追踪 信息 。 


4. Zipkin - Index x 


€ 





Finkin 
ZIPKIN 


Service Name Span Name Lookback 
k8s-app-monitor-agent Y all M 1 hour 
Annotations Query Duration (us) >= Limit 
foo/bar/ and cluster-foo and cache.miss 10 


E Sort 
Find Traces © 
Longest First 


Showing: 10 of 10 


Services: [CHE ey 


83.765ms 1 spans 
k8s-app-monitor-agent 100% 


59.213ms 1 spans 
k8s-app-monitor-agent 100% 
57.925ms 1 spans 
k8s-app-monitor-agent 100% 
51.891ms 1 spans 


k8s-app-monitor-agent 100% 


图 片 - Zipkin 页 面 


至 此 从 代码 提交 到 上 线 到 Kubernetes 集 群 上 并 集成 lstio service mesh 的 过 程 就 全 部 
完成 了 。 


Copyright © jimmysong.io 2017-2018 all right reserved * powered by 
GitbookUpdated at 2018-05-09 14:15:47 


迁移 传统 应 用 到 Kubernetes 步 骤 详 解 


Hadoop YARN 为 例 


本 文档 不 是 说 明 如 何在 kubernetes 中 开发 和 部 署 应 用 程序 ， 如 果 


你 相 


wen 





VA 


要 直接 开发 


应 用 程序 在 kubernetes 中 运行 可 以 参考 适用 于 kubernetes 的 应 用 开发 部 署 流程 。 


本 文 旨 在 说 明 如 何 将 已 有 的 应 用 程序 尤其 是 传统 的 分 布 式 应 用 程序 迁移 到 


kubernetes 中 。 如 果 该 类 应 用 程序 符合 云 原 生 应 用 规范 (如 12 因 素 法 则 


的 话 ， 那 


) 
么 迁移 会 比较 顺利 ， 否 则 会 遇 到 一 些 麻 烦 甚 至 是 阻碍 。 具 体 请 参考 迁移 至 云 原 生 应 


用 架构 。 


接 下 来 我 们 将 以 Spark on YARN with kubernetes 为 例 来 说 明 ， 该 例子 足够 复杂 也 
很 有 典型 性 ， 了 解 了 这 个 例子 可 以 帮助 大 家 将 自己 的 应 用 迁移 到 kubernetes 集群 
上 去 ， 代 码 和 配置 文件 可 以 在 这 里 找到 (本 文中 加 入 Spark 的 配置 ， 代 码 中 并 没 


有 包含 


， 读者 可 以 自己 配置 ) 。 


下 图 即 整 个 架构 的 示意 图 ， 代 码 和 详细 配置 文件 请 参 


yw 


ingress ` spark 配置 ) ， 所 有 的 进程 管理 和 容器 扩容 


考 
直 


kube-yarn (不 包含 
接 使 用 Makefile ° 
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Source htips: 


/igithub.com/raotsongjc/kubemetes-handbook 





图 片 - spark on yarn with kubernetes 





注意 : 该 例子 仅 用 来 说 明 具 体 的 步骤 划分 和 复杂 性 ， 在 生产 环境 应 用 还 有 待 验 证 ， 
请 谨 懂 使 用 。 


术语 


对 于 为 曾 接 触 过 kubernetes 或 对 云 平 台 的 技术 细节 不 太 了 解 的 人 来 说 ， 如 何 将 应 
用 迁移 到 kubernetes 中 可 能 是 个 头疼 的 问题 ， 在 行动 之 前 有 必要 先 了 解 整 个 过 程 
中 需要 用 到 哪些 概念 和 术语 ， 有 助 于 大 家 在 行动 中 达成 共识 。 


过 程 中 可 能 用 到 的 概念 和 术语 初步 整理 如 下 : 


迁移 传统 应 用 到 Kubernetes 中 以 Hadoop YARN 为 例 





Container 


Dockerfile 









Docker 


Images 





Spark on Yarn 


Terms 


source https://github.com/rootsongjc/kubernetes-handbook 






Hadoop 

YARN 

ResourceManager Configuration 

NodeManager Configuration 
Spark 

Namespace 

Label 

Pod 

Node 

Container Port 

Endpoint 

Service 

StatefulSet 

Pod IP 

Node IP 

Cluster IP 

Hostname 

Ingress 

Headless service 

ConfigMap 

YAML 


KubeDNS 
kubectl 


EK HA - Terms 
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为 了 讲解 整改 过 程 和 具体 细节 ， 我 们 所 有 操作 都 是 通过 命令 手动 完成 ， 不 使 用 自动 
化 工具 。 当 您 充分 了 解 到 其 中 的 细节 后 可 以 通过 自动 化 工具 来 优化 该 过 程 ， 以 使 其 
更 加 自动 和 高 效 ， 同 时 减少 因为 人 为 操作 失误 导致 的 迁移 失败 。 


迁移 应 用 


ResourceManager 
YARN 

Decomposing services 
spark client 

Building docker images my-docker-repo/hadoop:2.6.0:v1 

Migrating hadoop 
Configuration files 
YARN to kubernetes 
ConfigMaps 
Kubernetes YAML files Kubernetes resource objects 
hadoop-bootstrap.sh 
Bootstrap scripts 
Source https://github.com/rootsongjc/kubernetes-handbook spark-bootstrap.sh 





整个 迁移 过 程 分 为 如 下 几 个 步骤 : 
1. 将 原 有 应 用 拆 解 为 服务 


应 该 先 梳理 下 要 迁移 的 应 用 中 有 


我 们 不 是 一 上 来 就 开始 做 镜像 ， 写 配置 m 
些 是 不 变 的 部 分 。 


是 
哪些 可 以 作为 服务 运行 ， 哪 些 是 变 的 ， 哪 些 是 
服务 划分 的 原则 是 最 小 可 变 原 则 ， 这 个 同样 适用 于 镜像 制作 ， 将 服务 中 不 变 的 
部 分 编译 到 同一 个 镜像 中 。 


对 于 像 Spark on YARN 这 样 复 杂 的 应 用 ， 可 以 将 其 划分 为 三 大 类 服务 : 


o ResourceManager 
o NodeManager 
o Spark client 

2. 制作 镜像 


根据 拆 解 出 来 的 服务 ， 我 们 需要 制作 两 个 镜像 : 


o Hadoop 

o Spark (From hadoop docker image) 
为 我 们 运行 的 是 Spark on YARN > A36 Spark 依赖 与 Hadoop 镜像 ， 我 们 
在 Spark 的 基础 上 包装 了 一 个 web service 作为 服务 启动 。 


wr 


镜像 制作 过 程 中 不 需要 在 Dockerfile 中 指定 Entrypoint 和 CMD > 2% eap 
kubernetes 的 YAML 文件 中 指定 的 。 


Hadoop YARN 的 Dockerfile 参考 如 下 配置 。 


FROM my-docker-repo/jdk:7u80 


# Add native libs 
ARG HADOOP VERSION-2.6.0-cdh5.5.2 
## Prefer to download from server not use local storage 
ADD hadoop-${HADOOP_VERSION}.tar.gz /usr/local 
ADD ./lib/* /usr/local/hadoop-${HADOOP_VERSION}/1lib/native/ 
ADD ./jars/* /usr/local/hadoop-$([HADOOP VERSION?) /share/hadoo 
p/yarn/ 
ENV HADOOP PREFIX-/usr/local/hadoop \ 
HADOOP COMMON HOME-/usr/local/hadoop \ 
HADOOP HDFS HOME-/usr/local/hadoop \ 
HADOOP MAPRED HOME-/usr/local/hadoop \ 
HADOOP YARN. HOME-/usr/1local/hadoop \ 
HADOOP CONF DIR-/usr/local/hadoop/etc/hadoop \ 
YARN. CONF. DIR-/usr/1local/hadoop/etc/hadoop \ 
PATH-$(PATH) :/usr/local/hadoop/bin 


RUN \ 

cd /usr/local && ln -s ./hadoop-$(HADOOP VERSION) hadoop & 
& N 

rm -f ${HADOOP_PREFIX}/logs/* 


WORKDIR $HADOOP PREFIX 


4 Hdfs ports 

EXPOSE 50010 50020 50070 50075 50090 8020 9000 
# Mapred ports 

EXPOSE 19888 

#Yarn ports 

EXPOSE 8030 8031 8032 8033 8040 8042 8088 
ZOther ports 

EXPOSE 49707 2122 


3. 准备 应 用 的 配置 文件 


因为 我 们 只 制作 了 一 个 Hadoop 的 镜像 ， 而 需要 启动 两 个 服务 ， 这 就 要 求 在 服 
务 启动 的 时 候 必 须 加 载 不 同 的 配置 文件 ， 现 在 我 们 只 需要 准备 两 个 服务 中 需要 
同时 用 的 的 配置 的 部 分 


YARN 依赖 的 配置 在 artifacts 目录 下 ， 包 含 以 下 文件 : 


bootstrap.sh 
Capacity-scheduler. xml 
container -executor.cfg 
core-site.xml 
hadoop-env.sh 
hdfs-site.xml 
log4j.properties 
mapred-site.xml 
nodemanager exclude.txt 
slaves 
start-yarn-nm.sh 
start-yarn-rm.sh 
yarn-env.sh 
yarn-site.xml 


其 中 作为 bootstrap 启动 脚本 的 bootstrap.sh 也 包含 在 该 目录 下 ， 该 脚本 
pubes 见 下 文 。 


. Kubernetes YAML 文件 


根据 业务 的 特性 选择 最 适合 的 kubernetes 的 资源 对 象 来 运行 ， 因 为 在 YARN 
中 NodeManager 需要 使 用 主机 名 向 ResourceManger 注册 ， 因 此 需要 沿用 
YARN 原 有 的 服务 发 现 方式 ， 使 用 headless service 和 StatefulSet 资源 。 更 
多 资料 请 参考 StatefulSet 。 


所 有 的 Kubernetes YAML 配置 文件 存储 在 manifest 目录 下 ， 包 括 如 下 配 
置 : 


o yarn-cluster 的 namespace 配置 

o Spark、ResourceManager、NodeManager 的 headless service 和 
StatefulSet 配置 

o 需要 暴露 到 kubernetes 集群 外 部 的 ingress 配置 (ResourceManager 的 
Web ) 


kube-yarn-ingress.yaml 
spark-statefulset.yaml 
yarn-cluster-namespace.yaml 
yarn-nm-statefulset.yaml 
yarn-rm-statefulset.yaml 


5. Bootstrap 脚本 


Bootstrap 脚本 的 作用 是 在 启动 时 根据 Pod 的 环境 变量 、 主 机 名 或 其 他 可 以 区 
分 不 同 Pod 和 将 启动 角色 的 变量 来 修改 配置 文件 和 启动 服务 应 用 。 


该 脚本 同时 将 原来 YARN 的 日 志 使 用 stdout 输出 ， 便 于 使 用 kubect1 logs 
查看 日 志 或 其 他 日 志 收 集 工 具 进 行 日 志 收 集 。 


启动 脚本 bootstrap.sh 跟 Hadoop 的 配置 文件 同时 保存 在 artifacts 
目录 下 。 


该 脚本 根据 Pod 的 主机 名 ， 决 定 如 何 修改 Hadoop 的 配置 文件 和 启动 何 种 服 
务 。 bootstrap.sh 文件 的 部 分 代码 如 下 : 


if [[ "${HOSTNAME}" =~ "yarn-nm" ]]; then 
sed -i '/<\/configuration>/d' $HADOOP PREFIX/etc/hadoop/ya 
rn-site.xml 
cat >> $HADOOP PREFIX/etc/hadoop/yarn-site.xml ««- EOM 
«property» 
<name>yarn.nodemanager .resource.memory -mb</name> 
<value>${MY_MEM_LIMIT: -2048}</value> 
</property> 


<property> 
<name>yarn.nodemanager . resource. cpu-vcores</name> 
<value>${MY_CPU_LIMIT: -2}</value> 
</property> 
EOM 
echo '</configuration>' >> $HADOOP_PREFIX/etc/hadoop/yarn- 
site.xml 
cp ${CONFIG_DIR}/start-yarn-nm.sh $HADOOP PREFIX/sbin/ 
cd $HADOOP PREFIX/sbin 
chmod +x start-yarn-nm.sh 
./start-yarn-nm.sh 


TA 
if [[ $1 -- "-d" ]]; then 

until find ${HADOOP_PREFIX}/logs -mmin -1 | egrep -q '.*'; 
echo "'date': Waiting for logs..." ; do sleep 2 ; done 


tail -F ${HADOOP_PREFIX}/logs/* & 
while true; do sleep 1000; done 
fi 


ELLA 


从 这 部 分 中 代码 中 可 以 看 到 ， 如 果 Pod 的 主机 名 中 包含 yarn-nm 字段 则 向 
yarn-site.xml 配置 文件 中 增加 如 下 内 容 : 


<property> 
<name>yarn.nodemanager .resource.memory -mb</name> 
<value>${MY_MEM_LIMIT: -2048}</value> 

</property> 


<property> 
<name>yarn.nodemanager .resource.cpu-vcores</name> 
<value>${MY_CPU_LIMIT: -2}</value> 

</property> 


其 中 Mv MEM LIMIT 和 MY CPU LIMIT 是 kubernetes YAML 中 定义 的 环 
未 
AX 


境 变 量 ， 该 环境 变量 又 是 引用 的 Resource limit » 


所 有 的 配置 准备 完成 后 ， 执 行 start-yarn-nm.sh 脚本 启动 
NodeManager ° 


如 果 kubernetes YAML 中 的 container CMD args P&S -d WHEE $354 
NodeManger 并 tail 输出 NodeManager 的 日 志 到 标准 输出 。 


6. ConfigMaps 


将 Hadoop 的 配置 文件 和 bootstrap 脚本 作为 ConfigMap 资源 保存 ， 用 作 Pod 
启动 时 挂 载 的 volume。 


kubectl create configmap hadoop-config \ 
--from-file=artifacts/hadoop/bootstrap.sh \ 
--from-file=artifacts/hadoop/start-yarn-rm.sh \ 
--from-file=artifacts/hadoop/start-yarn-nm.sh \ 
--from-file=artifacts/hadoop/slaves \ 
--from-file=artifacts/hadoop/core-site.xml \ 
--from-file=artifacts/hadoop/hdfs-site.xml \ 
--from-file=artifacts/hadoop/mapred-site.xml \ 
--from-file=artifacts/hadoop/yarn-site.xml \ 
--from-file=artifacts/hadoop/capacity-scheduler.xml \ 
--from-file=artifacts/hadoop/container-executor.cfg \ 
--from-file=artifacts/hadoop/hadoop-env.sh \ 
--from-file=artifacts/hadoop/log4j.properties \ 
--from-file=artifacts/hadoop/nodemanager_exclude.txt \ 
--from-file=artifacts/hadoop/yarn-env.sh 

kubectl create configmap spark-config \ 
--from-file-artifacts/spark/spark-bootstrap.sh \ 
--from-file=artifacts/spark/spark-env.sh \ 
--from-file=artifacts/spark/spark-defaults.conf 


所 有 的 配置 完成 后 ， 可 以 可 以 使 用 kubectl 命令 来 启动 和 管理 集群 了 ， 我 们 编写 
Makefile， 您 可 以 直接 使 用 该 Makefile 封装 的 命令 实现 部 分 的 自动 化 。 
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使 用 StatefulSet 部 署 有 状态 应 用 
StatefulSet 这 个 对 人 象 是 专门 用 来 部 署 用 状态 应 用 的 ， 可 以 为 Pod 提 供 稳定 的 身份 标 
识 ， 包 括 hostname、 启 动 顺序 、DNS 名 称 等 。 


下 面 以 在 kubernetes1.6 版 本 中 部 署 zookeeper 和 kafka 为 例 讲解 StatefulSet 的 使 用 ， 
X P kafkaf& # T zookeeper ° 


Dockerfile 和 配置 文件 见 zookeeper 和 kafka » 


注 : 所 有 的 镜像 基于 CentOS 系 统 的 JDK 制 作 ， 为 我 的 私人 镜像 ， 外 部 无 法 访问 ， 
yaml 中 没有 配置 持久 化 存储 。 


部 署 Zookeeper 


Dockerfile 中 从 远程 获取 zookeeper 的 安装 文件 ， 然 后 在 定义 了 三 个 脚本 : 


e zkGenConfig.sh : 生成 Zookeeper 配 置 文件 
e zkMetrics.sh : 获取 zookeeper 的 metrics 
e zkOk.sh : 用 来 做 ReadinessProb 


我 们 在 来 看 下 这 三 个 脚本 的 执行 结果 : 
zkGenConfig.sh 


zkMetrics.sh 脚 本 实际 上 执行 的 是 下 面 的 命令 : 


$ echo mntr | nc localhost $ZK_CLIENT_PORT >& 1 
zk version 3.4.6-1569965, built on 02/20/2014 09:09 GMT 
zk avg latency 0 





zk_max_latency 5 

zk_min_latency 0 
zk_packets_received 427879 
zk_packets_sent 427890 
zk_num_alive_connections 3 
zk_outstanding_requests 0 
zk_server_state leader 
zk_znode_count 18 

zk_watch_count 3 
zk_ephemerals_count 4 
zk_approximate_data_size 613 
zk_open_file_descriptor_count 29 
zk_max_file_descriptor_count 1048576 
zk_followers 1 
zk_synced_followers 1 
zk_pending_syncs 0 


zkOk.sh 脚 本 实际 上 执行 的 是 下 面 的 命令 : 


$ echo ruok | nc 127.0.0.1 $ZK_CLIENT_PORT 
imok 
zookeeper.yaml 


下 面 是 启动 三 个 Zookeeper 实 例 的 yaml 配 置 文件 : 


apiVersion: vi 
kind: Service 


metadata: 
name: zk-svc 
labels: 
app: zk-svc 
spec: 
ports: 
- port: 2888 
name: server 
- port: 3888 
name: leader-election 
clusterIP: None 
selector: 
app: zk 


apiVersion: vi 
kind: ConfigMap 


使 用 StatefulSet 部 署 用 状态 应 用 


metadata: 
name: zk-cm 
data: 
jvm.heap: "1G" 
tick: "2000" 
init: "10" 
sync: "5" 


client.cnxns: "69" 
snap.retain: "3" 
purge.interval: "0" 
apiVersion: policy/vibetai 
kind: PodDisruptionBudget 
metadata: 
name: zk-pdb 
spec: 
selector: 
matchLabels: 
app: zk 
minAvailable: 2 
apiVersion: apps/vibetai 
kind: StatefulSet 
metadata: 
name: zk 
spec: 
serviceName: zk-svc 
replicas: 3 
template: 
metadata: 
labels: 
app: zk 
spec: 
affinity: 
podAntiAffinity: 
requiredDuringSchedulingIgnoredDuringExecution: 
- labelSelector: 
matchExpressions: 
= key: "app" 
operator: In 
values: 
- zk 
topologyKey: "kubernetes.io/hostname" 
containers: 
- name: k8szk 
imagePullPolicy: Always 
image: harbor-001.jimmysong.io/library/zookeeper:3.4.6 


resources: 
requests: 
memory: "2Gi" 
cpu: "500m" 
ports: 


- containerPort: 2181 
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name: client 
- containerPort: 2888 
name: server 
- containerPort: 3888 
name: leader-election 
env: 
- name : ZK REPLICAS 
value: "3" 
- name : ZK HEAP SIZE 
valueFrom: 
configMapKeyRef: 
name: zk-cm 
key: jvm.heap 
- name : ZK TICK TIME 


valueFrom: 
configMapKeyRef: 
name: zk-cm 
key: tick 
- name : ZK INIT LIMIT 
valueFrom: 
configMapKeyRef: 
name: zk-cm 
key: init 
- name : ZK SYNC LIMIT 
valueFrom: 
configMapKeyRef: 
name: zk-cm 
key: tick 
- name : ZK MAX CLIENT CNXNS 
valueFrom: 
configMapKeyRef: 


name: zk-cm 
key: client.cnxns 
- name: ZK SNAP RETAIN COUNT 
valueFrom: 
configMapKeyRef: 
name: zk-cm 
key: snap.retain 
- name: ZK PURGE INTERVAL 
valueFrom: 
configMapKeyRef: 
name: zk-cm 
key: purge.interval 
- name: ZK CLIENT PORT 
value: "2181" 
- name: ZK SERVER PORT 
value: "2888" 
- name: ZK ELECTION PORT 
value: "3888" 
command: 
- sh 
- -C 
- zkGenConfig.sh && zkServer.sh start-foreground 


readinessProbe: 
exec: 

command: 

- "ZkOk.sh" 
initialDelaySeconds: 10 
timeoutSeconds: 5 

livenessProbe: 
exec: 

command: 

- "ZkOk.sh" 
initialDelaySeconds: 10 
timeoutSeconds: 5 

securityContext: 
runAsUser: 1000 
fsGroup: 1000 


我 们 再 主要 下 上 面 那 三 个 脚本 的 用 途 。 


部 着 kafka 


Kafka 的 docker 镜 像 制 作 跟 zookeeper 类 似 ， 都 是 从 远程 下 载 安装 包 后 ， 解 压 安装 。 


与 Zookeeper 不 同 的 是 ， 只 要 一 个 脚本 ， 但 是 又 依赖 于 我 们 上 一 步 安装 的 
Zookeeper，kafkaGenConfig.sh 用 来 生成 kafka 的 配置 文件 。 


我 们 来 看 下 这 个 脚本 。 


#!/bin/bash 

HOST- hostname -s' 

if [[ $HOST =~ (.*)-([0-9]*)$ ]]; then 
NAME=${BASH_REMATCH[1]} 
ORD=${BASH_REMATCH[2]} 

else 
echo "Failed to extract ordinal from hostname $HOST" 
exit 1 

fi 


MY_ID=$( (ORD+1)) 

sed -i s"/broker.id=0/broker.id=$MY_ID/g" /opt/kafka/config/serv 
er.properties 

sed -i s'/zookeeper.connect-localhost:2181/zookeeper.connect-zk- 
0.zk-svc.brand.svc:2181, zk-1.zk-svc.brand.svc:2181, zk-2.zk-svc.b 
rand.svc:2181/g' /opt/kafka/config/server.properties 


该 脚本 根据 statefulset 生 成 的 pod 的 hostname 的 后 半截 数字 部 分 作为 broker ID > A 
时 再 替换 Zookeeper 的 地 址 。 


1& R| StatefulSet# 4 5] Ak A & M 


Kafka.yaml 


下 面 是 创建 3 个 kafka 实 例 的 yaml 配 置 。 


apiVersion: vi 
kind: Service 


metadata: 
name: kafka-svc 
labels: 
app: kafka 
spec: 
ports: 
- port: 9093 


name: server 
clusterIP: None 
selector: 
app: kafka 
apiVersion: policy/vibetai 
kind: PodDisruptionBudget 
metadata: 
name: kafka-pdb 
spec: 
selector: 
matchLabels: 
app: kafka 
minAvailable: 2 
apiVersion: apps/vibetai 
kind: StatefulSet 
metadata: 
name: kafka 
spec: 
serviceName: kafka-svc 
replicas: 3 
template: 
metadata: 
labels: 
app: kafka 
spec: 
affinity: 
podAntiAffinity: 
requiredDuringSchedulingIgnoredDuringExecution: 
- labelSelector: 
matchExpressions: 
_ key: "app" 
operator: In 
values: 
- kafka 
topologyKey: "kubernetes.io/hostname" 
podAffinity: 


619 


使 用 StatefulSet 部 署 用 状态 应 用 


preferredDuringSchedulingIgnoredDuringExecution: 
- weight: 1 
podAffinityTerm: 
labelSelector: 
matchExpressions: 
_ key: "app" 
operator: In 
values: 
- zk 
topologyKey: "kubernetes.io/hostname" 
terminationGracePeriodSeconds: 300 
containers: 
- name: k8skafka 
imagePullPolicy: Always 


image: harbor-001.jimmysong.io/library/kafka:2.10-0.8.2. 


resources: 
requests: 
memory: "1Gi" 
cpu: 500m 
env: 
- name: KF. REPLICAS 
value: "3" 
ports: 
- containerPort: 9093 
name: server 
command: 
- /bin/bash 
- -C 


- "/opt/kafka/bin/kafkaGenConfig.sh && /opt/kafka/bin/ka 


fka-server-start.sh /opt/kafka/config/server.properties" 


env: 
- name: KAFKA HEAP OPTS 
value : "-Xmx512M -Xms512M" 


- name: KAFKA OPTS 
value: "-Dlogging.level-DEBUG" 
readinessProbe: 
tcpSocket: 
port: 9092 
initialDelaySeconds: 15 
timeoutSeconds: 1 


e https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/ 

e kubernetes contrib - statefulsets 

e http://blog.kubernetes.io/201 7/01/running-mongodb-on-kubernetes-with- 
statefulsets.html 
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最 佳 实 践 概览 


本 章节 从 零 开 始 创 建 我 们 自己 的 kubernetes 集 群 ， 并 在 该 集群 的 基础 上 ， 配 置 服务 
发 现 、 负 载 均 衡 和 日 志 收 集 等 功能 ， 使 我 们 的 集群 能 够 成 为 一 个 真正 线 上 可 用 、 功 
能 完整 的 集群 。 


e 第 一 部 分 在 CentOS 上 部 署 kubernetes 集 群 中 介绍 了 如 何 通 过 二 进 制 文件 在 
CentOS 物 理 机 (也 可 以 是 公有 云 主机 ) 上 快速 部 署 一 个 kubernetes 集 群 。 
第 二 部 分 介绍 如 何在 kubernetes 中 的 服务 发 现 与 负载 均衡 。 

e. 第 三 部 分 介绍 如 何 运 维 kubernetes 集 群 。 

° o i akubemetes ta; he's = o 


第 
e 第 七 部 ‘sy ee een ere 
第 和 八 部 分 是 kubernetes 集 群 与 插件 的 更 新 升级 。 


Copyright © jimmysong.io 2017-2018 all right reserved > powered by 
GitbookUpdated at 2018-05-09 14:15:47 


CentOS 2 #kubernetes 47 
本 文档 最 初 是 基于 kubenetes1.6 版 本 编写 的 ， 对 于 kuberentes1.8 及 以 上 版 本 同 
样 适 用 ， 只 是 个 别 位 置 有 稍 许 变动 ， 变 动 的 地 方 我 将 特别 注 明 版 本 要 求 。 


本 系列 文档 介绍 使 用 二 进 制 部 署 kubernetes 集群 的 所 有 步骤 ， 而 不 是 使 用 
kubeadm 等 自动 化 方式 来 部 署 集群 ， 同 时 开启 了 集群 的 TLS 安 全 认证 ， 该 安装 步 
又 适用 于 所 有 bare metal 环 境 、on-premise 环 境 和 公有 云 环 境 。 


如 果 您 想 快速 的 在 自己 电脑 的 本 地 环境 下 使 用 虚拟 机 来 搭建 kubernetes 集 群 ， 
可 以 参考 本 地 分 布 式 开 发 环境 搭建 (使 用 Vagrant 和 Virtualbox) ° 


在 部 署 的 过 程 中 ， 将 详细 列 出 各 组 件 的 启动 参数 ， 给 出 配置 文件 ， 详 解 它们 的 含义 
和 可 能 遇 到 的 问题 。 


部 署 完成 后 ， 你 将 理解 系统 各 组 件 的 交互 原理 ， 进 而 能 快速 解决 实际 问题 。 


" 以 本 文档 主要 适合 于 那些 有 一 定 kubernetes 基础 ， 想 通过 步 部 署 的 方式 来 
学 习 和 了 解 系统 配置 、 运 行 原理 的 人 。 


注 : 本 文档 中 不 包括 docker 和 私有 镜像 仓库 的 安装 ， 安 装 说 明 中 使 用 的 镜像 来 自 
Google Cloud Platform ， 为 了 方便 国内 用 户 下 载 ， 我 将 其 克隆 并 上 传 到 了 时 速 云 
镜像 市 场 ， 供 大 家 免费 下 载 。 


欲 下 载 最 新 版 本 的 官方 镜像 请 访问 Google ATG ES EMR © 


供 所 有 的 配置 文件 


集群 安装 时 所 有 组 件 用 到 的 配置 文件 ， 包 含 在 以 下 目录 中 : 


e etc : service 的 环境 变量 配置 文件 
e manifest : kubernetes 应 用 的 yam| 文 件 
e systemd : systemd serivce 配 置 文件 


集群 详情 


e OS : CentOS Linux release 7.3.1611 (Core) 3.10.0-514.16.1.el7.x86_64 


e Kubernetes 1.6.0+〈 最 低 的 版 本 要 求 是 1.6 ) 

e Docker 1.12.5 (使 用 yum 安 装 ) 

e Etcd 3.1.5 

e Flannel 0.7.1 vxlan 或 者 host-gw 网 络 

e TLS 认证 通信 (所 有 组 件 ， 如 etcd ` kubernetes master 和 node) 

e RBAC 授权 

e kubelet TLS BootStrapping 

e kubedns ` dashboard ` heapster(influxdb ` grafana) ` EFK(elasticsearch ^ 
fluentd ` kibana) 集群 插件 

e 私有 docker 镜 像 仓库 harbor (请 自行 部 署 ，harbor 提 供 离线 安装 包 ， 直 接 使 用 
docker-compose 启 动 即 可 ) 


环境 说 明 

在 下 面 的 步骤 中 ， 我 们 将 在 三 台 CentOS 系 统 的 物理 机 上 部 署 具有 三 个 节点 的 
kubernetes1.6.0 集 群 。 

角色 分 配 如 下 


镜像 仓库 : 172.20.0.112， 域 名 为 harbor.jimmysong.io ， 为 私有 镜像 仓库 ， 请 
替换 为 公共 仓库 或 你 自己 的 镜像 仓库 地 址 。 


Master : 172.20.0.113 
Node : 172.20.0.113 ` 172.20.0.114 ` 172.20.0.115 


注意 : 172.20.0.113 这 台 主 机 master 和 node 复 用 。 所 有 生成 证 书 、 执 行 Kubectl 命 令 
的 操作 都 在 这 台 节 点 上 执行 。 一 旦 node 加 入 到 kubernetes 集 群 之 后 就 不 需要 再 登陆 
node? AT ° 


安装 前 的 准备 

1. 在 node 节 点 上 安装 docker1.12.5 
直接 使 用 yum install docker 

2. 关闭 所 有 节点 的 SELinux 


永久 方法 一 需要 重启 服务 器 


Q 一 


1. 


>DoonNDpamnkwnN 


. 该 部 署 操作 仅 是 搭建 成 了 一 个 可 用 kubernetes 集群 ， 而 很 多 地 方 还 


修改 /etc/selinux/config 文件 中 设置 SELINUX=disabled ， 然 后 重启 服务 


FLO 
临时 方法 一 设置 系统 参数 
使 用 命 


令 setenforce 0 


附 : setenforce 1 设置 SELinux 成 为 enforcing 模 式 setenforce 0 设置 SELinux 


成 为 permissive 模 式 
准备 harbor 私 有 镜像 仓库 


参考 : https://github.com/vmware/harbor 


. 创建 TLS 证 书 和 秘 铀 
. 创建 kubeconfig 文件 


创建 高 可 用 etcd 集 群 

装 kKubectl 命 令 行 工具 
部 署 master 节 点 

安装 flannel 网 络 插 件 
部 署 node 节 点 

安装 kubedns 插 件 
安装 dashboard 插 件 
安装 heapster 插 件 
安装 EFK 插 件 


由 于 启用 了 TLS 双向 认证 、RBAC 授权 等 严格 的 安全 机 制 ， 建 议 从 头 开始 部 
署 ， 而 不 要 从 中 间 开 始 ， 否 则 可 能 会 认证 、 授 权 等 失败 ! 


.部 署 过 程 中 需要 有 很 多 证 书 的 操作 ， 请 大 家 耐心 操作 ， 不 明白 的 操作 可 以 参考 


本 书 中 的 其 他 章节 的 解释 。 

需要 进行 
优化 ，heapster 插件 、EFK 插件 不 一 定 会 用 于 丨 实 的 生产 环境 中 ， 但 是 通过 部 
署 这 些 插件 ， 可 以 让 大 家 了 解 到 如 何 部 署 应 用 到 集群 上 。 


注 : 本 安装 文档 参考 了 opsnull 跟 我 一 步 步 部 署 kubernetes 集群 
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4) TLS 3x 45 $e fib 4: 


执行 下 列 步骤 前 建议 你 先 阅读 以 下 内 容 : 


e 管理 集群 中 的 TLS : 教 您 如 何 创建 TLS 证 书 

e kubelet 的 认证 授权 : 向 您 描述 如 何 通过 认证 授权 来 访问 kubelet 的 HTTPS 35 
点 。 

e TLS bootstrap : 介绍 如 何 为 kubelet 设置 TLS 客户 端 证 书 引导 
(bootstrap) 。 


注意 : 这 一 步 是 在 安装 配置 Kubernetes 的 所 有 步骤 中 最 容易 出 错 也 最 难于 排查 问题 
的 一 步 ， 而 这 却 刚好 是 第 一 步 ， 万 事 开头 难 ， 不 要 因为 这 点 困难 就 望而却步 。 


如 果 您 足够 有 信心 在 完全 不 了 解 自己 在 做 什么 的 情况 下 能 够 成 功 地 完成 了 这 一 步 的 
配置 ， 那 么 您 可 以 尽管 跳 过 上 面 的 几 篇 文章 直接 进行 下 面 的 操作 。 


kubernetes 系统 的 各 组 件 需要 使 用 TLS 证 书 对 通信 进行 加 密 ， 本 文档 使 用 
CloudFlare 的 PKI 工具 集 cfssl 来 生成 Certificate Authority (CA) 和 其 它 证 书 ; 


生成 的 CA 证 书 和 秘 钥 文件 如 下 : 


e ca-key.pem 

e ca.pem 

e kubernetes-key.pem 
e kubernetes.pem 

e kube-proxy.pem 

e kube-proxy-key.pem 
e admin.pem 

e admin-key.pem 


使 用 和 证书 的 组 件 如 下 : 


e etcd : 使 用 ca.pem ` kubernetes-key.pem ` kubernetes.pem : 

e kube-apiserver : 使 用 ca.pem ` kubernetes-key.pem ` kubernetes.pem : 
e kubelet : 使 用 ca.pem ; 

e kube-proxy : 使 用 ca.pem ` kube-proxy-key.pem ` kube-proxy.pem : 


e kubectl : 使 用 ca.pem ` admin-key.pem ` admin.pem : 
e kube-controller-manager : 使 用 ca-key.pem ` ca.pem 


注意 : 以 下 操作 都 在 master 节点 即 172.20.0.113 这 台 主 机 上 执行 ， 证 书 只 需要 创 
建 一 次 即 可 ， 以 后 在 向 集群 中 添加 新 节点 时 只 要 将 /etc/kubernetes/ 目录 下 的 证 书 
HA nep m Em 


安装 CFSSL 
方式 一 : 直接 使 用 二 进 制 源码 包 安 装 


wget https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 
chmod +x cfssl_linux-amd64 
mv cfssl_linux-amd64 /usr/local/bin/cfssl 


wget https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64 

chmod +x cfssljson_linux-amd64 

mv cfssljson_linux-amd64 /usr/local/bin/cfssljson 

wget https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64 
chmod +x cfssl-certinfo_linux-amd64 

mv cfssl-certinfo_linux-amd64 /usr/local/bin/cfssl-certinfo 


export PATH-/usr/local/bin:$PATH 


方式 二 : 使 用 go 命令 安装 


我 们 的 系统 中 安装 了 Go1.7.5， 使 用 以 下 命令 安装 更 快捷 : 


$ go get -u github.com/cloudflare/cfssl/cmd/... 

$ echo $GOPATH 

/usr/local 

$1s /usr/local/bin/cfssl* 

cfssl cfssl-bundle cfssl-certinfo cfssljson cfssl-newkey cfssl-s 
can 


在 $GOPATH/bin 目录 下 得 到 以 cfss| 开 头 的 几 个 命令 。 


注意 : 以 下 文章 中 出 现 的 cat 的 文件 名 如 果 不 存在 需要 手工 创建 。 


创建 CA (Certificate Authority) 


创建 CA 配置 文件 


mkdir /root/ssl 

cd /root/ssl 

cfssl print-defaults config > config.json 

cfssl print-defaults csr > csr.json 

# 根据 confFig,7son 文 件 的 格式 创建 如 下 的 ca-confFig,7Jsom 文 件 
# 过 期 时 间 设 置 成 了 87600h 

cat > ca-config.json <<EOF 


{ 
"signing": 4 
"default : 4 
"expiry": "87600h" 
ty 
"profiles": 4 
"kubernetes": 4 
"usages": [ 
"signing", 
"key encipherment", 
"server auth”, 
"client auth" 
], 
"expiry": "87600h" 
J 
j 
} 
} 
EOF 
字段 说 明 


e ca-config.json : 可 以 定义 多 个 profiles， 分 别 指定 不 同 的 过 期 时 间 、 使 用 
场景 等 参数 ; 后 续 在 签名 证 书 时 使 用 某 个 profile ; 

e signing : 表示 该 证 书 可 用 于 签名 其 它 证 书 ; 生成 的 ca.pem 证 书 中 

CA-TRUE ; 

server auth : 表示 client 可 以 用 该 CA 对 server 提 供 的 证 书 进 行 验证 ; 

e client auth :表示 server 可 以 用 该 CA 对 client 提 供 的 证 书 进行 验证 ; 


创建 CA 证 书签 名 请 求 


创建 ca-csr.json 文件 ， 内 容 如 下 : 


"CN": "kubernetes", 
"key" : { 
"algo": "rsa", 
"size": 2048 
) 


"names": [ 


News "CN" | 
"ST": "BeiJing", 
wg: Ws "BeiJing", 
Wy s "k8s", 
NOUN: "System" 
} 
Wea: { 
"expiry": "87600h" 


e "CN": Common Name °’ kube-apiserver 从 证 书 中 提取 该 字段 作为 请 求 的 用 户 
名 (User Name) ; 浏览 器 使 用 该 字段 验证 网 站 是 否 合法 ; 

e "O": Organization ，kube-apiserver 从 证 书 中 提取 该 字段 作为 请 求 用 户 所 
属 的 组 (Group) ; 


生成 CA 证 书 和 私 铀 


$ cfssl gencert -initca ca-csr.json | cfssljson -bare ca 
$ 1s ca* 
ca-config.json ca.csr ca-csr.json ca-key.pem ca.pem 


创建 kubernetes 证 书 


创建 kubernetes 证 书签 名 请 求 文件 kubernetes-csr.json 


"ON" : 

"hosts" [ 
"27.0.0.1" 
VII2.20 
"272.20 
"172,20 
"172.20 
"10.254. 


s 
B. 
(Bh 
Mom 


9. 


"kubernetes", 


, 


112", 
113", 
114", 
115", 
a" j 


"kubernetes", 


"kubernetes 
"kubernetes 
"kubernetes 
"kubernetes 


.default", 

.default.svc", 
.default.svc.cluster", 
.default.svc.cluster.local" 


1 
"algo": 
"size": 


"rsa", 
2048 
tr 


"names": [ 
{ 
"EN : 
CT" : 
p cw : 
moy : 
"ou" : 


"Cy" n 
"BeiJing", 

"BeiJing", 

"lec" 7 
"System" 


e wR hosts 字段 不 为 空 则 需要 指定 授权 使 用 该 证 书 的 IP 或 域名 列表 ， 由 于 该 
证 书后 续 被 etcd 集群 和 kubernetes master 集群 使 用 ， 所 以 上 面 分 别 
指定 了 etcd 集群 、 kubernetes master 集群 的 主机 上 IP 和 kubernetes 
服务 的 服务 IP (一般 是 kube-apiserver 指定 的 service-cluster-ip- 

range 网 段 的 第 一 个 |P， 如 10.254.0.1) ° 

这 是 最 小 化 安装 的 kubernetes 集 群 ， 包 括 一 个 私有 镜像 仓库 ， 
kubernetes 集 群 ， 以 上 物理 节点 的 IP 也 可 以 更 换 为 主机 名 。 


一 一 


个 节点 的 


生成 kubernetes 7x 4: fe 44 4A 


$ cfssl gencert -ca-ca.pem -ca-key=ca-key.pem -config-ca-config. 
json -profile-kubernetes kubernetes-csr.json | cfssljson -bare k 
ubernetes 

$ ls kubernetes* 
kubernetes.csr 
tes. pem 


kubernetes-csr.json kubernetes-key.pem kuberne 


或 者 直接 在 命令 行 上 指定 相关 参数 : 


echo '{"CN":"kubernetes", "hosts":[""],"key":{"algo":"rsa", "size" 
:2048}}' | cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=c 
a-config.json -profile=kubernetes -hostname="127.0.0.1,172.20.0. 
112,172.20.0.113,172.20.0.114,172.20.0.115, kubernetes, kubernetes 
.default" - | cfssljson -bare kubernetes 


创建 admin 证 书 


创建 admin 证 书签 名 请 求 文件 admin-csr.json 


{ 
"CN": "admin", 
"hosts™:-[],; 
"key": { 
"algo": "rsa", 
"size": 2048 
ty 
"names": [ 
{ 
CS CN"; 
"ST": “BeiJing", 
"L": "BeiJing", 
"Oo": "system:masters", 
"OU": "System" 
} 
] 
} 


e 后 续 kube-apiserver 使 用 RBAC 对 客户 端 ( 如 kubelet ^ kube- 
proxy ^ Pod ) 请 求 进行 授权 ; 
e kube-apiserver 预定 义 了 一 些 RBAC 使 用 的 RoleBindings ， 如 
cluster-admin 将 Group system:masters 与 Role cluster-admin 4% 
定 ， 该 Role 授予 了 调用 kube-apiserver 的 所 有 API 的 权限 ; 
e O 指定 该 证 书 的 Group A system:masters ， kubelet 使 用 该 证 书 访问 
kube-apiserver 了 时， 由 于 证 书 被 CA 签名 ， 所 以 认证 通过 ， 同 时 由 于 证 书 
用 户 组 为 经 过 预 授 权 的 system:masters ， 所 以 被 授予 访问 所 有 API 的 权 
FR ; 


注意 : 这 个 admin 证 书 ， 是 将 来 生成 管理 员 用 的 kube config 配置 文件 用 的 ， 现 在 我 
们 一 般 建议 使 用 RBAC 来 对 kubernetes 进行 角色 权限 控制 ， kubernetes 将 证 书 中 
的 CN 字段 作为 User ，O 〇 字段 作为 Group (具体 参考 Kubernetes 中 的 用 户 与 身份 
认证 授权 中 X509 Client Certs 一 段 ) ° 


在 搭建 完 kubernetes 集群 后 ， 我 们 可 以 通过 命令 : kubectl get 
clusterrolebinding cluster-admin -o yaml ,查看 到 clusterrolebinding 
cluster-admin 的 subjects 49 kind Æ Group * name Æ system:masters ° 
roleRef i£ ClusterRole cluster-admin ° 意思 是 凡是 
system:masters Group 的 user 或 者 serviceAccount 都 拥有 cluster- 
admin 的 角色 。 因 此 我 们 在 使 用 kubectl 命令 时 候 ， 才 拥有 整个 集群 的 管理 权 
限 。 可 以 使 用 kubectl get clusterrolebinding cluster-admin -o yaml 来 
查看 。 


$ kubectl get clusterrolebinding cluster-admin -0 yaml 
apiVersion: rbac.authorization.k8s.io/vi 
kind: ClusterRoleBinding 
metadata: 
annotations: 
rbac.authorization.kubernetes.io/autoupdate: "true" 
creationTimestamp: 2017-04-11T11:20:42Z 
labels: 
kubernetes.io/bootstrapping: rbac-defaults 
name: cluster-admin 
resourceVersion: "52" 
selfLink: /apis/rbac.authorization.k8s.io/vi/clusterrolebindin 
gs/cluster-admin 
uid: e61b97b2-1ea8-11e7-8cd7-f4e9d49f8edO 
roleRef: 
apiGroup: rbac.authorization.k8s.io 
kind: ClusterRole 
name: cluster-admin 


subjects: 
- apiGroup: rbac.authorization.k8s.io 
kind: Group 


name: system:masters 


生成 admin LE 49 $942 4 : 


$ cfssl gencert -ca-ca.pem -ca-key-ca-key.pem -config-ca-config. 
json -profile-kubernetes admin-csr.json | cfssljson -bare admin 
$ ls admin* 

admin.csr admin-csr.json admin-key.pem admin.pem 


创建 kube-proxy 证 书 


创建 kube-proxy 证 书签 名 请 求 文件 kube-proxy-csr.json 


{ 
"CN": "system: kube-proxy", 
"hosts": [45 
"key": { 
"algo": "rsa", 
"size": 2048 
ty 
"names": [ 
Mos "CN", 
"ST": "BeiJing", 
"L": "BeiJing", 
Lo "k8s", 
"OU": "System" 
} 
] 
} 


e CN 指定 该 证 书 的 User A system:kube-proxy ; 

e kube-apiserver 预定 义 的 RoleBinding cluster-admin 将 User 
system:kube-proxy 与 Role system:node-proxier 绑 定 ， 该 Role 授予 
了 调用 kube-apiserver Proxy 相关 API 的 权限 ; 


生成 kube-proxy 客户 端 证 书 和 私 钥 


$ cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config. 
json -profile=kubernetes kube-proxy-csr.json | cfssljson -bare 
kube-proxy 

$ ls kube-proxy* 

kube-proxy.csr kube-proxy-csr.json kube-proxy-key.pem kube-pr 
OXy.pem 


校 验证 书 


以 kubernetes 证 书 为 例 


使 用 opsnssl 命令 


$ openssl x509 -noout -text -in kubernetes.pem 


Signature Algorithm: sha256WithRSAEncryption 
Issuer: C=CN, ST=BeiJing, L=BeiJing, O=k8s, OU=System, CN 
=Kubernetes 
Validity 
Not Before: Apr 5 05:36:00 2017 GMT 
Not After : Apr 5 05:36:00 2018 GMT 
Subject: C-CN, ST-BeiJing, L-BeiJing, O-k8s, OU-System, 
CN-kubernetes 


X509v3 extensions: 
X509v3 Key Usage: critical 
Digital Signature, Key Encipherment 
X509v3 Extended Key Usage: 
TLS Web Server Authentication, TLS Web Client Au 
thentication 
X509v3 Basic Constraints: critical 
CA: FALSE 
X509v3 Subject Key Identifier: 
DD:52:04:43:10:13:A9:29:24:17:3A:0E:D7:14:DB:36: 
F8:6C: EO: EO 
X509v3 Authority Key Identifier: 
keyid:44:04:3B:60:BD:69:78:14:68:AF:A0:41:13:F6: 
17:07:13:63:58:CD 


X509v3 Subject Alternative Name: 

DNS:kubernetes, DNS:kubernetes.default, DNS:kube 
rnetes.default.svc, DNS:kubernetes.default.svc.cluster, DNS:kube 
rnetes.default.svc.cluster.local, IP Address:127.0.0.1, IP Addre 
ss:172.20.0.112, IP Address:172.20.0.113, IP Address:172.20.0.11 
4, IP Address:172.20.0.115, IP Address:10.254.0.1 


E 


e 确认 Issuer 字段 的 内 容 和 ca-csr.json 一 致 ; 

e 确认 Subject 字段 的 内 容 和 kubernetes-csr.json 一 致 ; 

e 确认 X509v3 Subject Alternative Name 字段 的 内 容 和 kubernetes- 
csr.json 一 致 ; 

e 确认 X509v3 Key Usage、Extended Key Usage 字段 的 内 容 和 ca- 
config.json 中 kubernetes profile 一 致 ; 


使 用 cfssl-certinfo 命令 


&| s TLS3E P fe ALA 


$ cfssl-certinfo -cert kubernetes.pem 


"subject": ( 
"common name": "kubernetes", 
"bountry": "ON". 
"organization": "k8s", 
"organizational unit": "System", 
"locality": "BeiJing", 
"province": "BeiJing", 
"names": [ 
VEN". 
"BeiJing", 
"BeiJing", 
"kgs" , 
"System", 
"kubernetes" 
] 
ty 
"issuer": { 
"common name": "Kubernetes", 
"country i "ON". 
"organization": "k8s", 
"organizational_unit": "System", 
"locality": "BeiJing", 
"province": "BeiJing", 
"names": [ 
"CN", 
"BeiJing", 
"BeiJing", 
"kgs" ; 
"System", 
"Kubernetes" 
] 


ty 
"serial_number": "17436049287242326347315197163229289570712902 


2309", 
"sans": [ 
"kubernetes", 
"kubernetes.default", 
"kubernetes.default.svc", 
"kubernetes.default.svc.cluster", 
"kubernetes.default.svc.cluster.local", 
27 6.0.4", 
48.64. 9,7. 
"198.254.0.1" 
], 
"not before": "2017-04-05T05:36:00Z", 
"not after": "2018-04-05T05:36:00Z", 
"sigalg": "SHA256WithRSA", 


636 


分 发 证 书 


将 生成 的 证 书 和 秘 铀 文件 (后 级 名 为 .pem ) 拷贝 到 所 有 机 器 的 
/etc/kubernetes/ssl 目录 下 备用 ; 


mkdir -p /etc/kubernetes/ssl 
cp *.pem /etc/kubernetes/ssl 


> 


RA 


e Generate self-signed certificates 

e Setting up a Certificate Authority and Creating TLS Certificates 
e Client Certificates V/s Server Certificates 

e 数字 证 书 及 CA 的 扫盲 介绍 

e TLS bootstrap 引导 程序 
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创建 kubeconfig 文件 


注意 : 请 先 参考 安装 Kubectl 命 令 行 工 具 ， 先 在 master 节点 上 安装 kubectl 然后 再 
进行 下 面 的 操作 。 


kubelet ^ kube-proxy 等 Node 机 器 上 的 进程 与 Master 机 器 的 kube- 
apiserver 进程 通信 时 需要 认证 和 授权 ; 


kubernetes 1.4 开始 支持 由 kube-apiserver 为 客户 端 生成 TLS 证 书 的 TLS 
Bootstrapping 功能 ， 这 样 就 不 需要 为 每 个 客户 端 生 成 证 书 了 ; 该 功能 当前 仅 支持 
A kubelet 生成 证 书 ; 

因为 我 的 master 节 点 和 node 节 点 复 用 ， 所 有 在 这 一 步 其 实 已 经 安装 了 kubectl。 参 
考 安装 Kubectl 命 令 行 工 具 。 

以 下 操作 只 需要 在 master 节 点 上 执行 ， 生 成 的 * ,kubeconfig 文件 可 以 直接 拷贝 
到 node 节 点 的 /etc/kubernetes 目录 下 。 


创建 TLS Bootstrapping Token 


Token auth file 


Token 可 以 是 任意 的 包含 128 bit 的 字符 串 ， 可 以 使 用 安全 的 随机 数 发 生 器 生成 。 


export BOOTSTRAP_TOKEN=$(head -c 16 /dev/urandom | od -An -t x | 
tr -d ' ') 

cat » token.csv ««EOF 

${BOOTSTRAP_TOKEN}, kubelet-bootstrap, 10001, system: kubelet-boots 
trap" 

EOF 


[EE | 
后 三 行 是 一 句 ， 直 接 复 制 上 面 的 脚本 运行 即 可 。 


注意 : 在 进行 后 续 操 作 前 请 检查 token.csv 文件 ， 确 认 其 中 的 
${BOOTSTRAP_TOKEN} 环境 变量 已 经 被 和 忠实 的 值 替换 。 


BOOTSTRAP_TOKEN 将 被 写 入 到 kube-apiserver 使 用 的 token.csv 文件 和 
kubelet 使 用 的 bootstrap.kubeconfig 文件 ， 如 果 后 续 重 新 生成 了 
BOOTSTRAP TOKEN ， 则 需要 : 


1. 更 新 token.csv 文件 ， 分 发 到 所 有 机 器 (master fe node) 的 /etc/kubernetes/ 
目录 下 ， 分 发 到 node 节 点 上 非 必 需 ; 

2. E% X bootstrap.kubeconfig 文件 ， 分 发 到 所 有 node 机 器 的 
/etc/kubernetes/ 目录 下 ; 

3. 重启 kube-apiserver 和 kubelet 进程 ; 

4. 重新 approve kubelet 的 csr 请 求 ; 


cp token.csv /etc/kubernetes/ 


创建 kubelet bootstrapping kubeconfig 文件 
执行 下 面 的 命令 时 需要 先 安装 Kubectl 命 令 ， 请 参考 安装 Kubectl 命 令 行 工 具 。 


cd /etc/kubernetes 
export KUBE_APISERVER="https://172.20.0.113:6443" 


kubectl config set-cluster kubernetes \ 
--certificate-authority=/etc/kubernetes/ssl/ca.pem \ 
--embed-certs=true \ 
--server=${KUBE_APISERVER} \ 
- -kubeconfig-bootstrap.kubeconfig 


L | aF FH HA 
] 


kubectl config set-credentials kubelet-bootstrap \ 
--token-$(BOOTSTRAP TOKEN) \ 
- -kubeconfig-bootstrap.kubeconfig 


zm p 


A 设置 上 下 文 参数 

kubectl config set-context default \ 
--cluster=kubernetes \ 
--user=kubelet-bootstrap \ 
- -kubeconfig-bootstrap.kubeconfig 


kubectl config use-context default --kubeconfig-bootstrap.kubeco 
nfig 


e --embed-certs A true 时 表示 将 certificate-authority 证 书写 入 


到 生成 的 bootstrap.kubeconfig 文件 中 ; 
e 设置 客户 端 认 证 参数 时 没有 指定 秘 钥 和 证 书 ， 后 续 由 kube-apiserver 自动 
生成 ; 


创建 kube-proxy kubeconfig 文件 


export KUBE_APISERVER="https://172.20.0.113:6443" 
HT ESAE 
kubectl config set-cluster kubernetes \ 
--certificate-authority=/etc/kubernetes/ssl/ca.pem \ 
--embed-certs=true \ 
--server=${KUBE_APISERVER} \ 
dec UU er proxy.kubeconfig 
kübectl contio pos credentials kube-proxy \ 
--client-certificate-/etc/kubernetes/ssl/kube-proxy.pem \ 
--client-key=/etc/kubernetes/ssl/kube-proxy-key.pem \ 
--embed-certs=true \ 
Mcr kube-proxy.kubeconfig 
# Trà 上 十: Pu AA 2 
kubect1 config set-context default \ 
--cluster=kubernetes \ 
--user=kube-proxy \ 
Mai kube-proxy.kubeconfig 
# Ue RAKE FSX 
kubectl Sonig use-context default --kubeconfig-kube-proxy.kubec 
onfig 


e 设置 集群 参数 和 客户 端 认证 参数 时 --embed-certs A true ， 这 会 将 
certificate-authority 、 client-certificate 和 client-key 指向 
的 证 书 文件 内 容 写 入 到 生成 的 kube-proxy.kubeconfig 文件 中 ; 

e kube-proxy.pem 人 证书 中 CN 为 system:kube-proxy * kube- 
apiserver 预定 义 的 RoleBinding cluster-admin 将 User system:kube- 
proxy 与 Role system:node-proxier #8 > X Role 授予 了 调用 kube- 
apiserver Proxy 相关 API 的 权限 ; 


分 发 kubeconfig 文件 
将 两 个 kubeconfig 文件 分 发 到 所 有 Node 机 器 的 /etc/kubernetes/ 目录 


cp bootstrap.kubeconfig kube-proxy.kubeconfig /etc/kubernetes/ 


KF kubeconfig 文件 的 更 多 信息 请 参考 使 用 kubeconfig 文件 配置 跨 集群 认证 。 
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创建 高 可 用 etcd 集群 


kuberntes 系统 使 用 etcd 存储 所 有 数据 ， 本 文档 介绍 部 署 一 个 三 节点 高 可 用 eted 
集群 的 步骤 ， 这 三 个 节点 复 用 kubernetes master 机 器 ， 分 别 命名 为 test- 
001.jimmysong.io ^ test-002.jimmysong.io ^ test- 


003.jimmysong.io 


e test-001.jimmysong.io : 172.20.0.113 
e test-002.jimmysong.io : 172.20.0.114 
e test-003.jimmysong.io : 172.20.0.115 


TLS i^t x fF 
需要 为 etcd 集群 创建 加 密 通 信 的 TLS 证 书 ， 这 里 复 用 以 前 创建 的 kubernetes 证 书 


cp ca.pem kubernetes-key.pem kubernetes.pem /etc/kubernetes/ssl 


e kubernetes 证 书 的 hosts 字段 列表 中 包含 上 面 三 台 机 器 的 IP， 否则 后 续 证 
书 校 验 会 失败 ; 


下 载 二 进 制 文件 


到 https://github.com/coreos/etcd/releases 页 面 下 载 最 新 版 本 的 二 进 制 
文件 
wget https://github.com/coreos/etcd/releases/download/v3.1.5/etc 
d-v3.1.5-linux-amd64. tar.gz 


tar -xvf etcd-v3.1.5-linux-amd64. tar.gz 
mv etcd-v3.1.5-linux-amd64/etcd* /usr/local/bin 


或 者 直接 使 用 yum 命 令 安装 : 


yum install etcd 


若 使 用 yum 安 装 ， 默 认 etcd 命 令 将 在 /usr/bin 目录 下 ， 注 意 修 改 下 面 的 
etcd.service 文件 中 的 启动 命令 地 址 为 /usr/bin/etcd ° 


创建 etcd 的 systemd unit 文件 


在 /usrlib/systemd/systerm/ 目 录 下 创建 文件 etcd.service， 内 容 如 下 。 注 意 替 换 IP 地 
址 为 你 自己 的 etcd 集 群 的 主机 IP。 


[Unit ] 

Description=Etcd Server 
After=network.target 
After=network-online.target 
Wants=network-online.target 
Documentation=https://github.com/coreos 


[Service ] 
Type=notify 
WorkingDirectory-/var/lib/etcd/ 
EnvironmentFile--/etc/etcd/etcd.conf 
ExecStart-/usr/local/bin/etcd \ 
--name $[ETCD NAME) \ 
--cert-file-/etc/kubernetes/ssl/kubernetes.pem \ 
- -key-file-/etc/kubernetes/ssl/kubernetes-key.pem \ 
--peer-cert-file-/etc/kubernetes/ssl/kubernetes.pem \ 
- -peer-key-file-/etc/kubernetes/ssl/kubernetes-key.pem \ 
--trusted-ca-file-/etc/kubernetes/ssl/ca.pem \ 
--peer-trusted-ca-file-/etc/kubernetes/ssl/ca.pem \ 
--initial-advertise-peer-urls $([ETCD INITIAL ADVERTISE PEER UR 
LS} \ 
--listen-peer-urls ${ETCD_LISTEN_PEER_URLS} \ 
--listen-client-urls ${ETCD_LISTEN_CLIENT_URLS},http://127.0.0 
2172379 X 
--advertise-client-urls ${ETCD_ADVERTISE_CLIENT_URLS} \ 
--initial-cluster-token ${ETCD_INITIAL_CLUSTER_TOKEN} \ 
--initial-cluster infrai-https://172.20.0.113:2380,infra2-http 
S://172.20.0.114: 2380, infra3-https://172.20.0.115:2380 \ 
--initial-cluster-state new \ 
--data-dir-$(ETCD DATA DIR) 
Restart-on-failure 
RestartSec=5 
LimitNOFILE=65536 


[Install] 
WantedBy=multi-user.target 


e 指定 etcd 的 工作 目录 为 /var/lib/etcd » RHA RA 
/var/lib/etcd ， 需 在 启动 服务 前 创建 这 个 目录 ， 否 则 启动 服务 的 时 候 会 报 


4i Failed at step CHDIR spawning /usr/bin/etcd: No such file or directory” : 

e 为 了 保证 通信 安全 ， 需 要 指定 etcd 1902-4 4A (cert-filefekey-file) ` Peers 通信 
的 公私 钥 和 CA 3 # (peer-cert-file ` peer-key-file ` peer-trusted-ca-file) ` 4 
端的 CA 证 书 (trusted-ca-file) ; 

e 创建 kubernetes.pem 证 书 时 使 用 的 kubernetes-csr.json 文件 的 

hosts 字段 包含 所 有 eted 节点 的 IP， 和 否则 证 书 校 验 会 出 错 ; 

e --initial-cluster-state 值 为 new 时 ，--name 的 参数 值 必 须 位 于 

--initial-cluster 列表 中 : 


完整 unit 文件 见 : etcd.service 


环境 变量 配置 文件 /etc/etcd/etcd.conf 。 


# [member ] 

ETCD NAME-infra1 

ETCD DATA DIR-"/var/lib/etcd" 

ETCD. LISTEN PEER. URLS-"https://172.20.0,113:2388" 
ETCD :LISTEN CLAIENT URLS-"https://172.20.0.113:227/9" 


Z [cluster] 

ETCD INITIAL ADVERTISE PEER URLS-z"https://172.20.0.113:2380" 
ETCD INITIAL CLUSTER TOKEN-"etcd-cluster" 

ETCD ADVERTISE CLIENT URLS-"https;//172.20,.0.113:2379" 


这 是 172.20.0.113 节 点 的 配置 ， 其 他 两 个 etcd 节 点 只 要 将 上 面 的 IP 地 址 改 成 相应 节 
点 的 IP 地 址 即 可 。ETCD_NAME 换 成 对 应 节点 的 infra1/2/3。 


尼 动 etcd 服务 


mv etcd.service /usr/lib/systemd/system/ 
systemctl daemon-reload 

systemctl enable etcd 

systemctl start etcd 

systemctl status etcd 


在 所 有 的 kubernetes master 节点 重复 上 面 的 步 又， 直到 所 有 机 器 的 etcd 服务 都 已 
启动 。 


验证 服务 


在 任 一 kubernetes master 机 器 上 执行 如 下 命令 : 


$ etcdctl \ 
--ca-file=/etc/kubernetes/ssl/ca.pem \ 
--cert-file=/etc/kubernetes/ssl/kubernetes.pem \ 
--key-file=/etc/kubernetes/ssl/kubernetes-key.pem \ 
cluster-health 
2017-04-11 15:17:09.082250 I | warning: ignoring ServerName for 
user-provided CA for backwards compatibility is deprecated 
2017-04-11 15:17:09.083681 I | warning: ignoring ServerName for 
user-provided CA for backwards compatibility is deprecated 
member 9a2ec640d25672e5 is healthy: got healthy result from http 
S://172.20.0.115:2379 
member bc6f27ae3be34308 is healthy: got healthy result from http 
S://172.20.0.114:2379 
member e5c92ea26c4edbaO is healthy: got healthy result from http 
S://172.20.0.113:2379 
cluster is healthy 


结果 最 后 一 行为 cluster is healthy 时 表示 集群 服务 正常 。 


关于 如 何在 etcd 中 查看 kubernetes 的 数据 ， 请 参考 使 用 etcdctl 访 问 kuberentes 数 
据 。 
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# kubectl 47 477 LA 


本 文档 介绍 下 载 和 配置 kubernetes 集群 命令 行 工具 kubelet $5 7H © 


下 载 kubectl 
注意 请 下 载 对 应 的 Kubernetes 版 本 的 安装 包 。 


wget https://d1.k8s.i0/v1.6.0/kubernetes-client-linux-amd64.tar. 
gz 

tar -xzvf kubernetes-client-linux-amd64. tar.gz 

cp kubernetes/client/bin/kube* /usr/bin/ 

chmod a+x /usr/bin/kube* 


创建 kubectl kubeconfig 文件 


export KUBE APISERVER-"https://172.20.0.113:6443" 
kubectl config set-cluster kubernetes \ 
--certificate-authority=/etc/kubernetes/ssl/ca.pem \ 
--embed-certs=true \ 
--server- ies _APISERVER} 


a up im 认 LE F 

kuibecti config set- credentials admin \ 
--client-certificate=/etc/kubernetes/ssl/admin.pem \ 
--embed-certs=true \ 
--client- key= /etc/kubernetes/ssl/admin-key.pem 

太 设置 上 下 文 参 数 

kubect1 config set-context kubernetes \ 
--cluster=kubernetes \ 
--user- admin 
it eo PATE FX 


beck! config use-context kubernetes 


e admin.pem 证 书 OU 字段 值 为 system:masters ， kube-apiserver fi 
定义 的 RoleBinding cluster-admin 将 Group system:masters 与 Role 
cluster-admin %< > % Role 授予 了 调用 kube-apiserver 相关 API 的 
权限 ; 
e 生成 的 kubeconfig 被 保存 到 ~/.kube/config 文件 ; 


注意 : ~/.kube/config 文件 拥有 对 该 集群 的 最 高 权限 ， 请 妥善 保管 。 


更 多 资料 


e kubectl4? 4-19 3i, 
e kubectl? 4 X75 X 
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#6 master 7? 点 


kubernetes master 节点 包含 的 组 件 : 


e kube-apiserver 
e kube-scheduler 
e kube-controller-manager 


目前 这 三 个 组 件 需要 部 署 在 同一 台 机 器 上 。 


e kube-scheduler ^ kube-controller-manager 和 kube-apiserver 三 
者 的 功能 紧密 相关 ; 

e 同时 只 能 有 一 个 kube-scheduler 、 kube-controller-manager 进程 处 
于 工作 状态 ， 如 果 运 行 多 个 ， 则 需要 通过 选举 产生 一 个 leader ; 


E. X 


e 暂时 未 实现 master 节 点 的 高 可 用 
e master 节 点 上 没有 部 署 flannel 网 络 插件 ， 如 果 想 要 在 master 节 点 上 也 能 访问 
ClusterlIP， 请 参考 下 一 节 部 署 node 节 点 中 的 配置 Flanneld 部 分 


TLS 证 书 文 件 


以 下 pem 证 书 文件 我 们 在 创建 TLS 证 书 和 秘 钥 这 一 步 中 已 经 创建 过 
T > token.csv 文件 在 创建 kubeconfig 文 件 的 时 候 创建 。 我 们 再 检查 一 下 。 


$ ls /etc/kubernetes/ssl 
admin-key.pem  admin.pem ca-key.pem ca.pem kube-proxy-key.pem 
kube-proxy.pem kubernetes-key.pem  kubernetes.pem 


下 载 最 新 版 本 的 二 进 制 文件 
有 两 种 下 载 方式 ， 请 注意 下 载 对 应 的 Kubernetes 版 本 。 
方式 一 


从 github release 页 面 下 载 发 布 版 tarball， 解 压 后 再 执行 下 载 脚本 


wget https://github.com/kubernetes/kubernetes/releases/download/ 
vi.6.0/kubernetes. tar.gz 

tar -xzvf kubernetes.tar.gz 

cd kubernetes 

./cluster/get-kube-binaries.sh 


AK 
从 CHANGELOG 页 面 下载 client 或 server tarball 文件 
server 的 tarball kubernetes-server-linux-amd64.tar.gz 已 经 包含 了 


client ( kubectl ) 二 进 制 文件 ， 所 以 不 用 单独 下 载 kubernetes-client- 
linux-amd64.tar.gz 文件 ; 


# wget https://dl.k8s.io/vi.6.0/kubernetes-client-linux-amd64.ta 
r.gz 

wget https://dl.k8s.io/vi1.6.0/kubernetes-server-linux-amd64.tar. 
gz 

tar -xzvf kubernetes-server-linux-amd64.tar.gz 

cd kubernetes 

tar -xzvf kubernetes-src.tar.gz 


将 二 进 制 文件 拷贝 到 指定 路 径 


cp -r server/bin/{kube-apiserver,kube-controller-manager, kube-sc 
heduler, kubectl, kube-proxy, kubelet} /usr/local/bin/ 


配置 和 启动 kube-apiserver 
创建 kube-apiserver 的 service 配 置 文件 


service 配 置 文件 /usr/lib/systemd/system/kube-apiserver.service 内 容 : 


[Unit ] 

Description=Kubernetes API Service 
Documentation=https://github.com/GoogleCloudPlatform/kubernetes 
After=network.target 

After=etcd.service 


[Service] 

EnvironmentFile=-/etc/kubernetes/config 

EnvironmentFile=-/etc/kubernetes/apiserver 

ExecStart=/usr/local/bin/kube-apiserver \ 
$KUBE_LOGTOSTDERR \ 
$KUBE_LOG_LEVEL \ 
$KUBE_ETCD_SERVERS \ 
$KUBE_API_ADDRESS \ 
$KUBE_API_PORT \ 
$KUBELET_PORT \ 
$KUBE_ALLOW_PRIV \ 
$KUBE_SERVICE_ADDRESSES \ 
$KUBE_ADMISSION_CONTROL \ 
$KUBE_API_ARGS 

Restart=on-failure 

Type=notify 

LimitNOFILE=65536 


[Install] 
WantedBy=multi-user.target 


/etc/kubernetes/config 文件 的 内 容 为 : 


HHH 

# kubernetes system config 

# 

# The following values are used to configure various aspects of 
all 

# kubernetes services, including 


kube-apiserver.service 

kube-controller-manager.service 

kube-scheduler.service 

kubelet.service 

kube-proxy.service 

# logging to stderr means we get it in the systemd journal 
KUBE LOGTOSTDERRz"'" --logtostderr-true" 


dk db dk dt dto dk 


# journal message level, © is debug 
KUBE LOG LEVEL-"--vzQ" 


# Should this cluster be allowed to run privileged docker contai 
ners 
KUBE ALLOW PRIV-z'--allow-privileged-true" 


# How the controller-manager, scheduler, and proxy find the apis 
erver 

ZKUBE MASTERz"--master-http://test-001.jimmysong.io:8080" 
KUBE_MASTER="--master=http://172.20.0.113: 8080" 


TA He a X 4+ Fl 3E Kube-apiserver ` kube-controller-manager ` kube-scheduler ` 
kubelet ` kube-proxy/£ J#] ° 


apiserver&c E 3 fF /etc/kubernetes/apiserver 内 容 为 : 


HHH 

## kubernetes system config 

HH 

## The following values are used to configure the kube-apiserver 

HH 

# 

## The address on the local server to listen to. 

ZKUBE API ADDRESS-"--insecure-bind-address-test-001.jimmysong.io 

KUBE API ADDRESS-"--advertise-address-172.20.0.113 --bind-addres 

$=172.20.0.113 --insecure-bind-address-172.20.0.113" 

# 

## The port on the local server to listen on. 

#KUBE_API_PORT=" - -port=8080" 

# 

## Port minions listen on 

ZKUBELET PORT-"--kubelet-port-10250" 

# 

## Comma separated list of nodes in the etcd cluster 

KUBE_ETCD_SERVERS="- -etcd-servers=https://172.20.0.113:2379,http 

S://172.20.0.114:2379, https://172.20.0.115:2379" 

# 

## Address range to use for services 

KUBE_SERVICE_ADDRESSES="- -service-cluster-ip-range=10.254.0.0/16 

# 

## default admission control policies 

KUBE_ADMISSION_CONTROL=" - -admission-control=ServiceAccount, Names 

paceLifecycle, NamespaceExists, LimitRanger, ResourceQuota" 

# 

## Add your own! 

KUBE API ARGS-"--authorization-mode-RBAC --runtime-config-rbac.a 

uthorization.k8s.io/vibeta1 --kubelet-https-true --experimental- 

bootstrap-token-auth --token-auth-file-/etc/kubernetes/token.csv 
--service-node-port-range-30000-32767 --tls-cert-file-/etc/kube 

rnetes/ssl/kubernetes.pem --tls-private-key-file-/etc/kubernetes 

/ssl/kubernetes-key.pem --client-ca-file-/etc/kubernetes/ssl/ca. 

pem --service-account-key-file-/etc/kubernetes/ssl/ca-key.pem -- 

etcd-cafile-/etc/kubernetes/ssl/ca.pem --etcd-certfile-/etc/kube 

rnetes/ssl/kubernetes.pem --etcd-keyfile-/etc/kubernetes/ssl/kub 

ernetes-key.pem --enable-swagger-ui-true --apiserver-count=3 --a 

udit-log-maxage-30 --audit-log-maxbackup=3 --audit-log-maxsize-1 

00 --audit-log-path-/var/lib/audit.log --event-ttl-ih" 


e --experimental-bootstrap-token-auth Bootstrap Token Authentication 
在 1.9 版 本 已 经 变 成 了 正式 feature， 参 数 名 称 改 为 --enable-bootstrap- 
token-auth 

e 如 果 中 途 修改 过 --service-cluster-ip-range 地 址 ， 则 必须 将 default 命 名 
空间 的 kubernetes 的 service 给 删除 ， 使 用 命令 : kubectl delete 


service kubernetes ， 然 后 系统 会 自动 用 新 的 ip 重建 这 个 service， 不 然 
apiserver 的 log 有 报错 the cluster IP x.x.x.x for service 
kubernetes/default is not within the service CIDR x.x.x.x/16; 
please recreate 

e --authorization-mode=RBAC 指定 在 安全 端口 使 用 RBAC 授权 模式 ， 拒 绝 
未 通过 授权 的 请 求 ; 

e kube-scheduler ` kube-controller-manager 一 般 和 kube-apiserver 部 署 在 同一 
人 台 机 器 上 ， 它 们 使 用 非 安 全 端口 和 kube-apiserver 通 信 ; 

e kubelet、kube-proxy、 kubectl 部 署 在 其 它 Node 节点 上 ， 如 果 通 过 安全 端口 
访问 kube-apiserver， 则 必须 先 通过 TLS 证 书 认 证 ， 再 通过 RBAC 授权 ; 

e kube-proxy、 kubectl 通过 在 使 用 的 证 书 里 指定 相关 的 User ^ Group 来 达 
过 RBAC 授权 的 目的 ; 

e 如 果 使 用 了 kubelet TLS Boostrap 机 制 ， 则 不 能 再 指定 --kubelet- 
certificate-authority ^ --kubelet-client-certificate 和 -- 
kubelet-client-key 选项 ， 否 则 后 续 kube-apiserver 校 验 kubelet 证 书 时 出 
3L ”x509: certificate signed by unknown authority" 错误 ; 

e --admission-control 值 必须 包含 ServiceAccount ; 

e --bind-address 不 能 为 127.0.0.1 ; 

e runtime-config 配置 为 rbac.authorization.k8s.io/vibetai ， 表 示 运 
行 时 的 apiVersion ; 

e --service-cluster-ip-range 指定 Service Cluster IP 地 址 段 ， 该 地 址 段 

能 路 由 可 达 ; 

e 缺 省 情况 下 kubernetes 对 象 保存 在 etcd /registry 路 径 下 ， 可 以 通过 -- 
etcd-prefix 参数 进行 调整 ; 

e 如 果 需 要 开通 http 的 无 认证 的 接口 ， 则 可 以 增加 以 下 两 个 参数 : --insecure- 
port=8080 --insecure-bind-address-127.0.0.1 。 注 意 ， 生 产 上 不 要 绑 
定 到 非 127.0.0.1 的 地 址 上 


Kubernetes 1.9 


e 对 于 Kubernetes1.9 集 群 ， 需 要 注意 配置 KUBE_API_ARGS 环境 变量 中 的 -- 
authorization-mode-Node,RBAC ， 增 加 对 Node 授权 的 模式 ， 否 则 将 无 法 
注册 node。 

e --experimental-bootstrap-token-auth Bootstrap Token Authentication 
在 kubernetes 1.9 版 本 已 经 废弃 ， 参 数 名 称 改 为 --enable-bootstrap- 


token-auth 


完整 unit JL kube-apiserver.service 


È 2 kube-apiserver 


systemctl daemon-reload 

systemctl enable kube-apiserver 
systemctl start kube-apiserver 
systemctl status kube-apiserver 


配置 和 局 动 kube-controller-manager 


创建 kube-controller-manager 的 serivce 配 置 文件 


文件 路 径 /usr/lib/systemd/system/kube-controller-manager.service 


[Unit ] 
Description=Kubernetes Controller Manager 
Documentation=https://github.com/GoogleCloudPlatform/kubernetes 


[Service ] 
EnvironmentFile=-/etc/kubernetes/config 
EnvironmentFile=-/etc/kubernetes/controller -manager 
ExecStart=/usr/local/bin/kube-controller-manager \ 
$KUBE_LOGTOSTDERR \ 
$KUBE_LOG_LEVEL \ 
$KUBE_MASTER \ 
$KUBE_CONTROLLER_MANAGER_ARGS 
Restart=on-failure 
LimitNOFILE=65536 


[Install] 
WantedBy=multi-user.target 


配置 文件 /etc/kubernetes/controller-manager ° 


HHH 
# The following values are used to configure the kubernetes cont 
roller-manager 


# defaults from config and apiserver should be adequate 


# Add your own! 

KUBE_CONTROLLER_MANAGER_ARGS="- -address=127.0.0.1 --service-clus 
ter-ip-range=10.254.0.0/16 --cluster-name=kubernetes --cluster-s 
igning-cert-file=/etc/kubernetes/ssl/ca.pem --cluster-signing-ke 
y-file-/etc/kubernetes/ssl/ca-key.pem  --service-account-private 
-key-file-/etc/kubernetes/ssl/ca-key.pem --root-ca-file-/etc/kub 
ernetes/ssl/ca.pem --leader-elect-true" 


e --service-cluster-ip-range 参数 指定 Cluster 中 Service 的 CIDR 范 围 ， 
该 网 络 在 各 Node 间 必 须 路 由 不 可 达 ， 必 须 和 kube-apiserver 中 的 参数 一 致 ; 

e --cluster-signing-* 指定 的 证 书 和 私 钥 文件 用 来 签名 为 TLS BootStrap 
创建 的 证 书 和 私 钥 ; 

e --root-ca-file 用 来 对 kube-apiserver 证 书 进行 校 验 ， 指 定 该 参数 后 ， 才 
会 在 Pod 容器 的 ServiceAccount 中 放置 该 CA 证 书 文件 ; 

e --address 值 必 须 为 127.0.0.1 * kube-apiserver #1 % scheduler 和 
controller-manager 在 同一 台 机 器 ; 


启动 kube-controller-manager 


systemctl daemon-reload 

systemctl enable kube-controller-manager 
systemctl start kube-controller-manager 
systemctl status kube-controller-manager 


我 们 启动 每 个 组 件 后 可 以 通过 执行 命令 kubectl get componentstatuses ， 来 
查看 各 个 组 件 的 状态 ; 


$ kubectl get componentstatuses 


NAME STATUS MESSAGE 

ERROR 

scheduler Unhealthy Get http://127.0.0.1:10251/heal 
thz: dial tcp 127.0.0.1:10251: getsockopt: connection refused 
controller -manager Healthy ok 

etcd-2 Healthy {"health": "true"} 

etcd-0 Healthy {"health": "true"} 

etcd-1 Healthy {"health": "true"} 


e 如 果 有 组 件 report unhealthy 请 参考 : https://github.com/kubernetes- 
incubator/bootkube/issues/64 


完整 unit 见 kube-controller-manager.service 


Ac a. #7 È a) kube-scheduler 


创建 kube-scheduler#) serivce At Z x 4+ 


文件 路 径 /usr/lib/systemd/system/kube-scheduler.service ° 


[Unit ] 
Description=Kubernetes Scheduler Plugin 
Documentation=https://github.com/GoogleCloudPlatform/kubernetes 


[Service] 
EnvironmentFile=-/etc/kubernetes/config 
EnvironmentFile--/etc/kubernetes/scheduler 
ExecStart-/usr/local/bin/kube-scheduler \ 
$KUBE LOGTOSTDERR \ 
$KUBE LOG LEVEL \ 
$KUBE MASTER \ 
$KUBE SCHEDULER ARGS 
Restart=on-failure 
LimitNOFILE=65536 


[Install] 
WantedBy=multi-user.target 


配置 文件 /etc/kubernetes/scheduler ° 


HHH 
# kubernetes scheduler config 


# default config should be adequate 


# Add your own! 
KUBE_SCHEDULER_ARGS="--leader-elect=true --address=127.0.0.1" 


e --address 值 必 须 为 127.0.0.1 ， 因 为 当前 kube-apiserver 期 望 
scheduler 和 controller-manager 在 同一 人 台 机 器 ; 


完整 unit 见 kube-scheduler.service 


B 3 kube-scheduler 


systemctl daemon-reload 

systemctl enable kube-scheduler 
systemctl start kube-scheduler 
systemctl status kube-scheduler 


验证 master 节点 功能 


$ kubectl get componentstatuses 


NAME STATUS MESSAGE ERROR 
scheduler Healthy ok 

controller -manager Healthy ok 

etcd-0 Healthy {"health": "true"} 

etcd-1 Healthy ("health": "true" 

etcd-2 Healthy ("health": "true" 
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安装 flannel 网 络 插件 


所 有 的 node 节 点 都 需要 安装 网 络 插件 才能 让 所 有 的 Pod 加 入 到 同一 个 局 域 网 中 ， 本 
文 是 安装 flannel 网 络 插件 的 参考 文档 。 


建议 直接 使 用 yum 安 装 flanneld， 除 非 对 版 本 有 特殊 需求 ， 默 认 安 装 的 是 0.7.1 版 本 
的 flannel ° 


yum install -y flannel 


service 配 置 文件 /usr/lib/systemd/system/flanneld.service ° 


[Unit] 

Description=Flanneld overlay address etcd agent 
After=network.target 
After=network-online. target 
Wants=network-online.target 

After=etcd.service 

Before=docker.service 


[Service ] 
Type=notify 
EnvironmentFile=/etc/sysconfig/flanneld 
EnvironmentFile=-/etc/sysconfig/docker -network 
ExecStart=/usr/bin/flanneld-start \ 
-etcd-endpoints=${FLANNEL_ETCD_ENDPOINTS} \ 
-etcd-prefix=${FLANNEL_ETCD_PREFIX} \ 
$FLANNEL_OPTIONS 
ExecStartPost=/usr/libexec/flannel/mk-docker-opts.sh -k DOCKER_N 
ETWORK_OPTIONS -d /run/flannel/docker 
Restart=on-failure 


[Install] 


WantedBy=multi-user.target 
RequiredBy=docker .service 


/etc/sysconfig/flanneld 配置 文件 : 


# Flanneld configuration options 


# etcd url location. Point this to the server where etcd runs 
FLANNEL_ETCD_ENDPOINTS="https://172.20.0.113:2379, https://172.20 
“0 11412379, htt ps://172,20,0.115123709" 


# etcd config key. This is the configuration key that flannel q 
ueries 


# For address range assignment 
FLANNEL_ETCD_PREFIX="/kube-centos/network" 


# Any additional options that you want to pass 
FLANNEL_OPTIONS="-etcd-cafile=/etc/kubernetes/ssl/ca.pem -etcd-c 
ertfile-/etc/kubernetes/ssl/kubernetes.pem -etcd-keyfile=/etc/ku 
bernetes/ssl/kubernetes-key.pem" 


如 果 是 多 网 卡 〈 例 如 vagrant 环 境 ) ， 则 需要 在 FLANNEL_OPTIONS 中 增加 指定 的 
外 网 出 口 的 网 卡 ， 例 如 -iface=eth2 


在 etcd 中 创建 网 络 配 置 


执行 下 面 的 命令 为 docker 分 配 IP 地 址 段 。 


etcdctl --endpoints-https://172.20.0.113:2379,https://172.20.0.1 
14:2379,https://172.20.0.115:2379 \ 
--ca-file=/etc/kubernetes/ssl/ca.pem \ 
--cert-file=/etc/kubernetes/ssl/kubernetes.pem \ 
--key-file=/etc/kubernetes/ssl/kubernetes-key.pem \ 
mkdir /kube-centos/network 
etcdctl --endpoints=https://172.20.0.113:2379,https://172.20.0.1 
14:2379,https://172.20.0.115:2379 \ 
--ca-file=/etc/kubernetes/ssl/ca.pem \ 
--cert-file=/etc/kubernetes/ssl/kubernetes.pem \ 
--key-file=/etc/kubernetes/ssl/kubernetes-key.pem \ 
mk /kube-centos/network/config '("Network":"172.30.0.0/16", "Su 
bnetLen" :24, "Backend": {"Type":"vxlan"}}' 


如 果 你 要 使 用 host-gw 模式 ， 可 以 直接 将 vxlan 改 成 host-gw 即 可 。 


注 : 参考 网 络 和 集群 性 能 测试 那 节 ， 最 终 我 们 使 用 的 host-gw 模式 ， 关 于 flannel 
支持 的 backend 模 式 

JL : https://github.com/coreos/flannel/blob/master/Documentation/backends.md ° 
B 


flannel 


systemctl daemon-reload 

systemctl enable flanneld 
systemctl start flanneld 
systemctl status flanneld 


现在 查询 etcd 中 的 内 容 可 以 看 到 : 


$etcdctl --endpoints=${ETCD_ENDPOINTS} \ 
--ca-file-/etc/kubernetes/ssl/ca.pem \ 
--cert-file=/etc/kubernetes/ssl/kubernetes.pem \ 
--key-file=/etc/kubernetes/ssl/kubernetes-key.pem \ 
ls /kube-centos/network/subnets 
/kube-centos/network/subnets/172.30.14.0-24 
/kube-centos/network/subnets/172.30.38.0-24 
/kube-centos/network/subnets/172.30.46.0-24 


$etcdctl --endpoints=${ETCD_ENDPOINTS} \ 
--ca-file=/etc/kubernetes/ssl/ca.pem \ 
--cert-file=/etc/kubernetes/ssl/kubernetes.pem \ 
--key-file=/etc/kubernetes/ssl/kubernetes-key.pem \ 
get /kube-centos/network/config 

{ "Network": "172.30.0.0/16", "SubnetLen": 24, "Backend": { "Typ 

e": "vxlan" } } 


$etcdctl --endpoints=${ETCD_ENDPOINTS} \ 
--ca-file=/etc/kubernetes/ssl/ca.pem \ 
--cert-file=/etc/kubernetes/ssl/kubernetes.pem \ 
--key-file=/etc/kubernetes/ssl/kubernetes-key.pem \ 
get /kube-centos/network/subnets/172.30.14.0-24 
("PublicIP":"172.20.0.114", "BackendType":"vxlan", "BackendData": { 
"VtepMAC":"56:27:70:10:88:22"]] 


$etcdctl --endpoints=${ETCD_ENDPOINTS} \ 
--ca-file=/etc/kubernetes/ssl/ca.pem \ 
--cert-file=/etc/kubernetes/ssl/kubernetes.pem \ 
--key-file=/etc/kubernetes/ssl/kubernetes-key.pem \ 
get /kube-centos/network/subnets/172.30.38.0-24 
("PublicIP":"172.20.0.115", "BackendType":"vxlan", "BackendData" : f 
"VtepMAC":"12:82:83:59:cf:b8"}} 


$etcdctl --endpoints=${ETCD_ENDPOINTS} \ 
--ca-file=/etc/kubernetes/ssl/ca.pem \ 
--cert-file=/etc/kubernetes/ssl/kubernetes.pem \ 
--key-file=/etc/kubernetes/ssl/kubernetes-key.pem \ 
get /kube-centos/network/subnets/172.30.46.0-24 
("PublicIP":"172.20.0.113", "BackendType":"vxlan", "BackendData" : f 
"VtepMAC":"e6:b2:fd:f6:66:96"}} 


如 果 可 以 查看 到 以 上 内 容 证 明 flannel 已 经 安装 完成 ， 下 一 步 是 在 node 节 点 上 安装 和 
配置 docker、kubelet、kube-proxy 等 ， 请 参考 下 一 节 部 团 node 节 点 。 
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#8 X-node $ A 


Kubernetes node Y & & 440 F 24 : 


e Flanneld : 参考 我 之 前 写 的 文章 Kubernetes 基 于 Flannel 的 网 络 


配置 TLS， 现 在 需要 在 service 配 置 文件 中 增加 TLS 配 置 ， 安 装 过 程 请 参考 上 一 


节 安 装 flannel 网 络 插件 。 


e Docker1.12.5 : docker 的 安装 很 简单 ， 这 里 也 不 说 了 ， 但 是 需要 注意 docker 的 


配置 。 


e kubelet : 直接 用 二 进 制 文件 安装 
e kube-proxy : 直接 用 二 进 制 文件 安装 


55 


š 


fay 4| 


. 确认 在 上 一 步 中 我 们 安装 本 
. 安装 配置 docker 后 启动 


mae 


验证 


目录 和 文件 


我 们 再 检查 一 下 三 个 节点 上 ， 经 过 前 几 步 操 


件 。 


$ ls /etc/kubernetes/ssl 
admin-key.pem admin.pem 


注意 : 每 台 node 上 都 需要 安装 flannel，master 节点 上 可 以 不 安装 。 
^r 


置 的 网 络 插件 flannel 已 启动 且 运行 正常 


. 安装 配置 Kubelet、kube-proxy 后 局 动 


作 我 们 已 经 创建 了 如 下 的 证 书 和 配置 文 


ca-key.pem ca.pem kube-proxy-key.pem 


kube-proxy.pem kubernetes-key.pem  kubernetes.pem 


$ ls /etc/kubernetes/ 


apiserver  bootstrap.kubeconfig config controller-manager kub 
elet kube-proxy.kubeconfig proxy scheduler ssl token.csv 


Bc à Docker 


如 果 您 使 用 yum 的 方式 安装 的 flannel 则 不 需要 执行 mk-docker-opts.sh 文 件 这 一 
步 ， 参 考 Flannel 官 方 文 档 中 的 Docker Integration ° 


he RAR A AS E yum X “flannel * ab A 3; XT # flannel github release ¥ “tar 

E * ARE JG & R44 — 4 mk-docker-opts.sh xX 4} > 2 flannel release Jt MF 3X d e 
版 本 的 安装 包 ， 该 脚本 见 mk-docker-opts.sh， 因 为 我 们 使 用 yum 安 装 所 以 不 需要 执 
人 


这 个 文件 是 用 来 Generate Docker daemon options based on flannel env 
file ° 


使 用 systemctl 命令 启动 flanneld 后 ， 会 自动 执行 ./mk-docker-opts.sh -i 4 
成 如 下 两 个 文件 环境 变量 文件 : 


e /run/flannel/subnet.env 


FLANNEL_NETWORK=172.30.0.0/16 
FLANNEL_SUBNET=172.30.46.1/24 
FLANNEL_MTU=1450 
FLANNEL_IPMASQ=false 


e /run/docker_opts.env 


DOCKER_OPT_BIP="- -bip=172.30.46.1/24" 
DOCKER_OPT_IPMASQ="- -ip-masq=true" 
DOCKER_OPT_MTU="- -mtu=1450" 


Docker 将 会 读 取 这 两 个 环境 变量 文件 作为 容器 启动 参数 。 
注意 : 不 论 您 用 什么 方式 安装 的 flannel ， 下 面 这 一 步 是 必 不 可 少 的 。 
yum 方 式 安 装 的 flannel 


修改 docker 的 配置 文件 /usr/lib/systemd/system/docker.service ， 增 加 一 条 
环境 变量 配置 : 


EnvironmentFile=-/run/flannel/docker 


/run/flannel/docker 文件 是 flannel 启 动 后 自动 生成 的 ， 其 中 包含 了 docker 启 动 
时 需要 的 参数 。 


二 进 制 方式 安装 的 flannel 


修改 docker 的 配置 文件 /usr/lib/systemd/system/docker.service ， 增 加 如 下 
几 条 环境 变量 配置 : 


EnvironmentFile=-/run/docker_opts.env 
EnvironmentFile=-/run/flannel/subnet.env 


这 两 个 文件 是 mk-docker-opts.sh 脚本 生成 环境 变量 文件 默认 的 保存 位 置 ， 
docker 启 动 的 时 候 需 要 加 载 这 几 个 配置 文件 才 可 以 加 入 到 flannel 创 建 的 虚拟 网 络 
里 。 


所 以 不 论 您 使 用 何 种 方式 安装 的 flannel， 将 以 下 配置 加 入 到 docker.service 中 
可 确保 万 无 一 失 。 


EnvironmentFile=-/run/flannel/docker 
EnvironmentFile=-/run/docker_opts.env 
EnvironmentFile--/run/flannel/subnet.env 
EnvironmentFile--/etc/sysconfig/docker 
EnvironmentFile=-/etc/sysconfig/docker -storage 
EnvironmentFile=-/etc/sysconfig/docker -network 
EnvironmentFile=-/run/docker_opts.env 


请 参考 dockerservice 中 的 配置 。 


A 2h docker 
重启 了 docker 后 还 要 重启 kubelet， 这 时 又 遇 到 问题 ，kubelet 启 动 失败 。 报 错 : 


Mar 31 16:44:41 test-002.jimmysong.io kubelet[81047]: error: fai 
led to run Kubelet: failed to create kubelet: misconfiguration: 
kubelet cgroup driver: "cgroupfs" is different from docker cgrou 
p driver: "systemd" 


i& Xt kubelet4 docker&7 cgroup driver 不 一 臻 导致 的 ，kubelet 局 动 的 时 候 有 个 一 
cgroup-driver 参数 可 以 指定 为 "cgroupfs" 或 者 “systemd”。 


--cgroup-driver string Driver 
that the kubelet uses to manipulate cgroups on the host. Possi 
ble values: 'cgroupfs', 'systemd' (default "cgroupfs") 


配置 docker 的 service 配 置 文件 /usr/lib/systemd/system/docker.service ， 


设置 ExecStart 中 的 --exec-opt native.cgroupdriver=systemd 。 


安装 和 配置 Kubelet 


kubernets1.8 
相对 于 kubernetes1.6 集 群 作 须 进 行 的 配置 有 : 
对 于 kuberentes1.8 集 群 ， 必 须 关 闭 sSwap， 和 否则 kubelet 局 动 将 失败 。 


修改 /etc/fstab 将 ，swap 系 统 注释 掉 。 


kubelet 启动 时 向 kube-apiserver 发 送 TLS bootstrapping 请 求 ， 需 要 先 将 
bootstrap token 文件 中 的 kubelet-bootstrap /#] P f system:node-bootstrapper 
cluster 角色 (role) ， 然 后 kubelet 才能 有 权限 创建 认证 请 求 (certificate signing 
requests) : 


cd /etc/kubernetes 

kubectl create clusterrolebinding kubelet-bootstrap \ 
--clusterrole=system:node-bootstrapper \ 
- -user=kubelet -bootstrap 


e --user=kubelet-bootstrap 有 是 在 /etc/kubernetes/token.csv 文件 中 
指定 的 用 户 名 ， 同 时 也 写 入 了 /etc/kubernetes/bootstrap.kubeconfig 
文件 ; 


下 载 最 新 的 kubelet 和 kube-proxy 二 进 制 文件 
注意 请 下 载 对 应 的 Kubernetes 版 本 的 安装 包 。 


wget https://d1.k8s.io/v1.6.0/kubernetes-server-linux-amd64.tar. 
gz 

tar -xzvf kubernetes-server-linux-amd64. tar.gz 

cd kubernetes 

tar -xzvf kubernetes-src.tar.gz 

cp -r ./server/bin/(kube-proxy, kubelet) /usr/local/bin/ 


A] Æ kubelet£ service & E. X4 


x fF /usr/lib/systemd/system/kubelet.service ° 


[Unit] 

Description-Kubernetes Kubelet Server 
Documentation=https://github.com/GoogleCloudPlatform/kubernetes 
After=docker.service 

Requires=docker.service 


[Service] 
WorkingDirectory=/var/lib/kubelet 
EnvironmentFile=-/etc/kubernetes/config 
EnvironmentFile=-/etc/kubernetes/kubelet 
ExecStart=/usr/local/bin/kubelet \ 
$KUBE_LOGTOSTDERR \ 
$KUBE_LOG_LEVEL \ 
$KUBELET_API_SERVER \ 
$KUBELET_ADDRESS \ 
$KUBELET_PORT \ 
$KUBELET_HOSTNAME \ 
$KUBE_ALLOW_PRIV \ 
$KUBELET_POD_INFRA_CONTAINER \ 
$KUBELET_ARGS 
Restart=on-failure 


[Install] 
WantedBy=multi-user.target 


kubelet 的 配置 文件 /etc/kubernetes/kubelet 。 其 中 的 IP 地 址 更 改 为 你 的 每 台 
node 节 点 的 IP 地 址 。 


注意 : 在 启动 kubelet 之 前 ， 需 要 先 手 动 创建 /var/1ib/kubelet 目录 。 
下 面 是 kubelet 的 配置 文件 /etc/kubernetes/kubelet : 
kubernetes1.8 

相对 于 kubenrete1.6 的 配置 变动 : 


e 对 于 kuberentes1.8 集 群 中 的 kubelet 配 置 ， 取 消 了 KUBELET_API_SERVER 的 配 
置 ， 而 改 用 kubeconfig 文 件 来 定义 master 地 址 ， 所 以 请 注释 
i$ KUBELET API SERVER 配置 。 


HHH 
## kubernetes kubelet (minion) config 


# 

ZZ The address for the info server to serve on (set to 0.0.0.0 o 
r "" for all interfaces) 
KUBELET_ADDRESS=" - -address=172.20.0.113" 

# 


## The port for the info server to serve on 

#KUBELET_PORT="- -port=10250" 

# 

## You may leave this blank to use the actual hostname 
KUBELET_HOSTNAME=" - -hostname-override=172.20.0.113" 

# 

## location of the api-server 

ZZ COMMENT THIS ON KUBERNETES 1.8+ 

KUBELET API SERVER-"--api-servers-http://172.20.0.113:8080" 

# 

## pod infrastructure container 

KUBELET POD INFRA CONTAINER-'--pod-infra-container-image-harbor - 
001.jimmysong.io/library/pod-infrastructure:rhel7" 

E 

## Add your own! 

KUBELET_ARGS="--cgroup-driver=systemd --cluster-dns-10.254.0.2 - 
-experimental-bootstrap-kubeconfig-/etc/kubernetes/bootstrap.kub 
econfig --kubeconfig-/etc/kubernetes/kubelet.kubeconfig --requir 
e-kubeconfig --cert-dir-/etc/kubernetes/ssl --cluster-domain-clu 
ster.local --hairpin-mode promiscuous-bridge --serialize-image-p 
ulls-false" 


e 如 果 使 用 systemd 方 式 启 动 ， 则 需要 额外 增加 两 个 参数 --runtime- 
cgroups-/systemd/system.slice --kubelet- 
cgroups-/systemd/system.slice 

e --experimental-bootstrap-kubeconfig 在 1.9 版 本 已 经 变 成 了 -- 
bootstrap-kubeconfig 

e --address 不 能 设置 为 127.0.0.1 * GR Pods 访问 kubelet 的 API 
接口 时 会 失败 ， 因 为 Pods 访问 的 127.0.0.1 指向 自己 而 不 是 kubelet ; 


e 如 果 设 置 了 --hostname-override 选项 ， 则 kube-proxy 也 需要 设置 该 
选项 ， 否 则 会 出 现 找 不 到 Node 的 情况 ; 
e "--cgroup-driver 配置 成 systemd ， 不 要 使 用 cgroup * FRM 


CentOS 系统 中 kubelet 将 启动 失败 (保持 docker 和 kubelet 中 的 cgroup driver 
配置 一 致 即 可 ， 不 一 定 非 使 用 systemd ) ° 

e --experimental-bootstrap-kubeconfig 指向 bootstrap kubeconfig 文 
件 ，kubelet 使 用 该 文件 中 的 用 户 名 和 token 向 kube-apiserver A iX TLS 
Bootstrapping 请 求 ; 


e 管理 员 通 过 了 CSR 请 求 后 ，kubelet 自动 在 --cert-dir 目录 创建 证 书 和 私 
铀 文件 ( kubelet-client.crt 和 kubelet-client.key )， 然 后 写 入 -- 
kubeconfig 文件 ; 

e 建议 在 --kubeconfig 配置 文件 中 指定 kube-apiserver 地 址 ， 如 果 未 指 
X --api-servers 选项 ， 则 必须 指定 --require-kubeconfig 选项 后 才 
从 配置 文件 中 读 取 kube-apiserver 的 地 址 ， 否 则 kubelet 启动 后 将 找 不 到 
kube-apiserver (日 志 中 提示 未 找到 API Server) ， kubectl get nodes 不 
会 返回 对 应 的 Node 信息 ; 

e --cluster-dns 指定 kubedns 的 Service IP( 可 以 先 分 配 ， 后 续 创建 
kubedns 服务 时 指定 该 IP)， --cluster-domain 指定 域名 后 级 ， 这 两 个 参 
数 同时 指定 后 才 会 生效 ; 

e --cluster-domain 指定 pod 启动 时 /etc/resolve.conf 文件 中 的 

search domain ， 起 初 我 们 将 其 配置 成 了 _ cluster.1ocal， ， 这 样 在 解析 
service 的 DNS 名 称 时 是 正常 的 ， 可 是 在 解析 headless service 中 的 FQDN 
pod name 的 时 候 却 错误 ， 因 此 我 们 将 其 修改 为 cluster.local ， 去 掉 嘴 后 
面 的 "点 号 “就 可 以 解决 该 问题 ， 关 于 kubernetes 中 的 域名 /服务 名 称 解析 请 参 
见 我 的 另 一 篇 文章 。 

e --kubeconfig=/etc/kubernetes/kubelet.kubeconfig 中 指定 
的 kubelet.kubeconfig 文件 在 第 一 次 启动 kubelet 之 前 并 不 存在 ， 请 看 下 
文 ， 当 通过 CSR 请 求 后 会 自动 生成 kubelet.kubeconfig 文件 ， 如 果 你 的 节 
点 上 已 经 生成 了 -/.kube/config 文件 ， 你 可 以 将 该 文件 拷贝 到 该 路 径 下 ， 
并 重 命名 为 kubelet.kubeconfig ， 所 有 node 节 点 可 以 共用 同一 个 
kubelet.kubeconfig 文 件 ， 这 样 新 添加 的 节点 就 不 需要 再 创建 CSR 请 求 就 能 自 
动 添加 到 kubernetes 集 群 中 。 同 样 ， 在 任意 能 够 访问 到 kubernetes 集 群 的 主机 
上 使 用 kubect1 --kubeconfig 命令 操作 集群 时 ， 只 要 使 
用 -/.kube/config 文件 就 可 以 通过 权限 认证 ， 因 为 这 里 面 已 经 有 认证 信息 
并 认为 你 是 admin 用 户 ， 对 集群 拥有 所 有 权限 。 

e KUBELET POD INFRA CONTAINER 是 基础 镜像 容器 ， 这 里 我 用 的 是 私有 镜像 
仓库 地 址 ， 大 家 部 署 的 时 候 需 要 修改 为 自己 的 镜像 。 我 上 传 了 一 个 到 时 速 云 
上 ， 可 以 直接 docker pull index.tenxcloud.com/jimmy/pod- 
infrastructure F ° pod-infrastructure 镜像 是 Redhat 制 作 的 ， 大 小 
接近 80M， 下 载 比较 耗 时 ， 其 实 该 镜像 并 不 运行 什么 具体 进程 ， 可 以 使 用 
Google 的 pause 镜 像 gcr.io/google containers/pause-amd64:3.0 ， 这 个 
镜像 只 有 300 多 K， 或 者 通过 DockerHub 下 载 jimmysong/pause- 
amd64:3.0 ° 


完整 unit JL kubelet.service 


JA i kublet 


systemctl daemon-reload 
systemctl enable kubelet 
systemctl start kubelet 
systemctl status kubelet 


通过 kublet 的 TLS 证 书 请 求 


kubelet 首次 启动 时 向 kube-apiserver 发 送 证 书签 名 请 求 ， 必 须 通 过 后 kubernetes 
系统 才 会 将 该 Node 加 入 到 集群 。 


查看 未 授权 的 CSR 请 求 


$ kubectl get csr 

NAME AGE REQUESTOR CONDITION 
csr -2b308 4m kubelet-bootstrap Pending 

$ kubectl get nodes 

No resources found. 


通过 CSR 请 求 


$ kubectl certificate approve csr-2b308 
certificatesigningrequest "csr-2b308" approved 
$ kubectl get nodes 

NAME STATUS AGE VERSION 
10.64.3.7 Ready 49m v1.6.1 


自动 生成 了 kubelet kubeconfig 文件 和 公私 铀 


$ ls -1 /etc/kubernetes/kubelet.kubeconfig 

-rw------- 1 root root 2284 Apr 7 02:07 /etc/kubernetes/kubelet 
. kubeconfig 

$ ls -1 /etc/kubernetes/ssl/kubelet* 

-rw-r--r-- 1 root root 1046 Apr 7 02:07 /etc/kubernetes/ssl/kub 
elet-client.crt 


-rw------- 1 root root 227 Apr 7 02:04 /etc/kubernetes/ssl/kub 
elet-client.key 


-rw-r--r-- 1 root root 1103 Apr 7 02:07 /etc/kubernetes/ssl/kub 
elet.crt 


-rw------- 1 root root 1675 Apr 7 02:07 /etc/kubernetes/ssl/kub 


假如 你 更 新 kubernetes 的 证 书 ， 只 要 没有 更 新 token.csv ， 当 重启 kubelet 后 ， 该 

node 就 会 自动 加 入 到 kuberentes 集 群 中 ， 而 不 会 重新 发 

iÉ certificaterequest ， 也 不 需要 在 master 节 点 上 执行 kubectl certificate 

approve 操作 。 前 提 是 不 要 删除 node 节 点 上 

的 /etc/kubernetes/ssl/kubelet* 和 /etc/kubernetes/kubelet .kubeconfic 
文件 。 否 则 kubelet 启 动 时 会 提示 找 不 到 证 书 而 失败 。 


注意 : 如 果 启 动 kubelet 的 时 候 见 到 证 书 相 关 的 报错 ， 有 个 trick 可 以 解决 这 个 问题 ， 
可 以 将 master 节 点 上 的 ~/.kube/config 文件 (该 文件 在 安装 kubectl 命 令 行 工 具 
这 一 步 中 将 会 自动 生成 ) 拷贝 到 node 节 点 

的 /etc/kubernetes/kubelet.kubeconfig 位 置 ， 这 样 就 不 需要 通过 CSR， 当 
kubelet 启 动 后 就 会 自动 加 入 的 集群 中 。 

配置 kube-proxy 


4t % conntrack 


yum install -y conntrack-tools 


创建 kube-proxy 的 service 配 置 文件 


文件 路 径 /usr/lib/systemd/system/kube-proxy.service ° 


[Unit ] 

Description=Kubernetes Kube-Proxy Server 
Documentation=https://github.com/GoogleCloudPlatform/kubernetes 
After=network.target 


[Service ] 
EnvironmentFile=-/etc/kubernetes/config 
EnvironmentFile=-/etc/kubernetes/proxy 
ExecStart=/usr/local/bin/kube-proxy \ 
$KUBE_LOGTOSTDERR \ 
$KUBE_LOG_LEVEL \ 
$KUBE_MASTER \ 
$KUBE_PROXY_ARGS 
Restart=on-failure 
Limi tNOFILE=65536 


[Install] 
WantedBy=multi-user.target 


kube-proxy 配 置 文件 /etc/kubernetes/proxy ° 


sy 


HHH 
# kubernetes proxy config 


# default config should be adequate 


# Add your own! 

KUBE_PROXY_ARGS=" - -bind-address=172.20.0.113 --hostname-override 

=172.20.0.113 --kubeconfig=/etc/kubernetes/kube-proxy.kubeconfig 
--cluster-cidr=10.254.0.0/16" 


e --hostname-override 参数 值 必 须 与 kubelet 的 值 一 致 ， 否 则 kube-proxy 
启动 后 会 找 不 到 该 Node， 从 而 不 会 创建 任何 iptables 规则 ; 

e kube-proxy 根据 --cluster-cidr 判断 集群 内 部 和 外 部 流量 ， 指 定 -- 
cluster-cidr 或 --masquerade-all 选项 后 kube-proxy 才 会 对 访问 
Service IP 的 请 求 做 SNAT ; 

e --kubeconfig 指定 的 配置 文件 诅 入 了 kube-apiserver 的 地 址 、 用 户 名 、 证 
书 、 秘 钥 等 请 求 和 认证 信息 ; 

e 预定 义 的 RoleBinding cluster-admin 将 User system:kube-proxy 与 
Role system:node-proxier 绑 定 ， 该 Role 授予 了 调用 kube-apiserver 
Proxy 相关 API 的 权限 ; 


整 unit JL kube-proxy.service 


启动 kube-proxy 


systemctl daemon-reload 

systemctl enable kube-proxy 
systemctl start kube-proxy 
systemctl status kube-proxy 


验证 测试 


我 们 创建 一 个 nginx 的 service 试 一 下 集群 是 否 可 用 。 


$ kubectl run nginx --replicas=2 --labels="run=load-balancer-exa 
mple" --image-harbor-001.jimmysong.io/library/nginx:1.9  --port- 
80 

deployment "nginx" created 

$ kubectl expose deployment nginx --type=NodePort --name=example 
-service 

service "example-service" exposed 

$ kubectl describe svc example-service 


Name: example-service 

Namespace: default 

Labels: run-load-balancer-example 
Annotations: <none> 

Selector: run=load-balancer -example 
Type: NodePort 

IP: 10.254.62.207 

Port: <unset> 80/TCP 

NodePort: <unset> 32724/TCP 
Endpoints: 172.30.60.2:80,172.30.94.2:80 
Session Affinity: None 

Events: <none> 


$ curl "10.254.62.207:80" 
<!DOCTYPE html> 


<html> 
<head> 
<title>welcome to nginx!</title> 
<style> 
body { 
width: 35em; 
margin: © auto; 
font-family: Tahoma, Verdana, Arial, sans-serif; 
} 
</style> 
</head> 
<body> 


<hi>welcome to nginx!</h1> 

<p>If you see this page, the nginx web server is successfully in 
stalled and 

working. Further configuration is required.</p> 


<p>For online documentation and support please refer to 
«a href="http://nginx.org/">nginx.org</a>.<br/> 
Commercial support is available at 

<a href="http://nginx.com/">nginx.com</a>.</p> 


<p><em>Thank you for using nginx.</em></p> 
</body> 
</html> 


提示 : 上 面 的 测试 示例 中 使 用 的 nginx 是 我 的 私有 镜像 仓库 中 的 镜像 harbor- 
001.jimmysong.io/library/nginx:1.9 ， 大 家 在 测试 过 程 中 请 换 成 自己 的 nginx 
镜像 地 址 。 


访问 172.20.0.113:32724 或 172.20.0.114:32724 或 


者 172.20.0.115:32724 都 可 以 得 到 nginx 的 页 面 。 


E C Q © 172.20.0.113:32724 a 
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Welcome to nginx! 


If you see this page, the nginx web server is successfully installed and 
working. Further configuration is required. 


For online documentation and support please refer to nginx.org. 
Commercial support is available at nginx.com. 


Thank you for using nginx. 


El A - welcome nginx 
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官方 的 yaml 文 件 目 录 : kubernetes/cluster/addons/dns ° 


该 插件 直接 使 用 kubernetes 部 署 ， 官 方 的 配置 文件 中 包含 以 下 镜像 : 


gcr.io/google containers/k8s-dns-dnsmasq-nanny-amd64:1.14.1 
gcr.io/google containers/k8s-dns-kube-dns-amd64:1.14.1 
gcr.io/google containers/k8s-dns-sidecar-amd64:1.14.1 


我 clone 了 上 述 镜 像 ， 上 传 到 我 的 私有 镜像 仓库 : 


harbor-001.jimmysong.io/library/k8s-dns-dnsmasq-nanny-amd64:1.14 
zd. 

harbor-001.jimmysong.io/library/k8s-dns-kube-dns-amd64:1.14.1 
harbor-001.jimmysong.io/library/k8s-dns-sidecar-amd64:1.14.1 


同时 上 传 了 一 份 到 时 速 云 备 份 : 


index.tenxcloud.com/jimmy/k8s-dns-dnsmasq-nanny-amd64:1.14.1 
index.tenxcloud.com/jimmy/k8s-dns-kube-dns-amd64:1.14.1 
index.tenxcloud.com/jimmy/k8s-dns-sidecar-amd64:1.14.1 


以 下 yaml 配 置 文件 中 使 用 的 是 私有 镜像 仓库 中 的 镜像 。 


kubedns-cm. yaml 
kubedns-sa. yaml 
kubedns-controller.yaml 
kubedns-svc.yaml 


已 经 修改 好 的 yam 文件 见 : ../manifests/kubedns 


系统 预定 义 的 RoleBinding 


预定 义 的 RoleBinding system:kube-dns 将 kube-system 命名 空间 的 ”kube- 
dns ServiceAccount 4 system:kube-dns Role 绑 定 ， 该 Role 具有 访问 kube- 
apiserver DNS 相关 API 的 权限 ; 


$ kubectl get clusterrolebindings system:kube-dns -o yaml 
apiVersion: rbac.authorization.k8s.io/vibeta1 
kind: ClusterRoleBinding 
metadata: 
annotations: 
rbac.authorization.kubernetes.io/autoupdate: "true" 
creationTimestamp: 2017-04-11T11:20:42Z 
labels: 
kubernetes.io/bootstrapping: rbac-defaults 
name: system: kube-dns 
resourceVersion: "58" 
selfLink: /apis/rbac.authorization.k8s.io0/vibetai/clusterroleb 
indingssystem%3Akube-dns 
uid: e61f4d92-1ea8-11e7-8cd7 -f4e9d49f8edO 
roleRef: 
apiGroup: rbac.authorization.k8s.io 
kind: ClusterRole 
name: system:kube-dns 
subjects: 
- kind: ServiceAccount 
name: kube-dns 
namespace: kube-system 


kubedns-controller.yaml 中 定义 的 Pods 时 使 用 了 kubedns-sa.yaml 文件 
定义 的 kube-dns ServiceAccount， 所 以 具有 访问 kube-apiserver DNS 相关 API 
的 权限 。 


配置 kube-dns ServiceAccount 


配置 kube-dns 服务 


$ diff kubedns-svc.yaml.base kubedns-svc.yaml 
30c30 
< clusterIP: | PILLAR DNS SERVER . 


> clusterIP: 10.254.0.2 


e spec.clusterlP = 10.254.0.2 > PpP A 4448 x: f kube-dns Service IP > & “IP X; 
要 和 kubelet 的 --cluster-dns 参数 值 一 致 ; 


配置 kube-dns Deployment 


$ diff kubedns-controller.yaml.base kubedns-controller.yaml 
58c58 


< image: gcr.io/google_containers/k8s-dns-kube-dns-amd64 
:1.14.1 

> image: harbor-001.jimmysong.io/library/k8s-dns-kube-dn 
s-amd64:v1.14.1 

88c88 

< - --domain- PILLAR DNS DOMAIN . 

> - --domain=cluster.local. 

92c92 

< . PILLAR FEDERATIONS DOMAIN MAP . 

> # PILLAR__FEDERATIONS__DOMAIN__MAP. 

110c110 

< image: gcr.io/google containers/k8s-dns-dnsmasq-nanny- 


amd64:1.14.1 


> image: harbor-001.jimmysong.io/library/k8s-dns-dnsmasq 
-nanny-amd64:v1.14.1 

129c129 

< - --server=/__PILLAR__DNS__DOMAIN__/127.0.0.1710053 

> - --server=/cluster.local./127.0.0.1#10053 

148c148 

< image: gcr.io/google containers/k8s-dns-sidecar-amd64: 
1.14.1 

> image: harbor-001.jimmysong.io/library/k8s-dns-sidecar 


-amd64:v1.14.1 
161, 162c161, 162 


< - --probe=kubedns, 127.0.0.1:10053, kubernetes.default.s 
vc. PILLAR DNS DOMAIN ,5,A 

< - --probe-dnsmasq,127.0.0.1:53, kubernetes.default.svc. 
. PILLAR DNS DOMAIN ,5,A 

> - --probe=kubedns, 127.0.0.1:10053, kubernetes.default.s 
vc.cluster.local.,5,A 

> - --probe=dnsmasq, 127.0.0.1:53, kubernetes.default.svc. 


cluster.local.,5,A 


e 使 用 系统 已 经 做 了 RoleBinding 的 kube-dns ServiceAccount » iA IK P LA 
访问 kube-apiserver DNS 相关 API 的 权限 ; 


执行 所 有 定义 文件 


$ pwd 

/root/kubedns 

$ ls *.yaml 

kubedns-cm.yaml  kubedns-controller.yaml  kubedns-sa.yaml  kubed 
ns-svc.yaml 

$ kubectl create -f . 


检查 kubedns 功能 
新 建 一 个 Deployment 


$ cat my-nginx.yaml 
apiVersion: extensions/vibeta1 
kind: Deployment 
metadata: 
name: my-nginx 
spec: 
replicas: 2 
template: 
metadata: 
labels: 
run: my-nginx 
spec: 
containers: 
- name: my-nginx 
image: harbor-001.jimmysong.io/library/nginx:1.9 
ports: 
- containerPort: 80 
$ kubectl create -f my-nginx.yaml 


Export 该 Deployment, 生成 my-nginx 服务 


$ kubectl expose deploy my-nginx 

$ kubectl get services --all-namespaces |grep my-nginx 

default my -nginx 10.254.179.239 <none> 80/TCP 
42m 


创建 另 一 个 Pod: € /etc/resolv.conf 是 否 包含 kubelet 配置 的 -- 
cluster-dns 和 --cluster-domain ， 是 否 能 够 将 服务 my-nginx 解析 到 
Cluster IP 10.254.179.239 ° 


$ kubectl create -f nginx-pod.yaml 

$ kubectl exec nginx -i -t -- /bin/bash 

root@nginx:/# cat /etc/resolv.conf 

nameserver 10.254.0.2 

search default.svc.cluster.local. svc.cluster.local. cluster.loc 
al. jimmysong.io 

options ndots:5 


root@nginx:/# ping my-nginx 

PING my-nginx.default.svc.cluster.local (10.254.179.239): 56 dat 
a bytes 

76 bytes from 119.147.223.109: Destination Net Unreachable 

^C--- my-nginx.default.svc.cluster.local ping statistics --- 


root@nginx:/# ping kubernetes 

PING kubernetes.default.svc.cluster.local (10.254.0.1): 56 data 
bytes 

^C--- kubernetes.default.svc.cluster.local ping statistics --- 
11 packets transmitted, © packets received, 100% packet loss 


root@nginx:/# ping kube-dns.kube-system.svc.cluster.local 

PING kube-dns.kube-system.svc.cluster.local (10.254.0.2): 56 dat 
a bytes 

^C--- kube-dns.kube-system.svc.cluster.local ping statistics --- 
6 packets transmitted, 0 packets received, 100% packet loss 


从 结果 来 看 ，service 名 称 可 以 正常 解析 。 


注意 : 直接 ping ClusterlP 是 ping 不 通 的 ，ClusterlP 是 根据 IPtables 路 由 到 服务 的 
endpoint 上 ， 只 有 结合 ClusterIP 加 端口 才能 访问 到 对 应 的 服务 。 
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注意 : 本 文档 中 安装 的 是 kubernetes dashboard v1.6.0， 安 装 新 版 的 
dashboard 请 参考 升级 dashboard ° 
官方 文件 目 
3k : https://github.com/kubernetes/kubernetes/tree/master/cluster/addons/dashbo 
ard 


我 们 使 用 的 文件 如 下 : 


$ ls *.yaml 
dashboard-controller.yaml dashboard-service.yaml dashboard-rbac 
.yaml 


已 经 修改 好 的 yaml 文件 见 : ../manifests/dashboard 


文件 中 的 kubernetes-dashboard-amd64 镜 像 为 本 地 镜像 地 址 需要 修改 为 对 应 的 镜像 
地 址 和 版 本 : 


kubernetes 1.7.11 可 以 使 用 此 镜像 地 址 : registry.cn- 
qingdao.aliyuncs.com/haitao/kubernetes-dashboard-amd64:v1.7.0 替换 
dashboard-controlleryaml 文件 中 的 镜像 地 址 


由 于 kube-apiserver 启用 了 RBAC 授权 ， 而 官方 源码 目录 的 dashboard- 
controller.yaml 没有 定义 授权 的 ServiceAccount， 所 以 后 续 访 问 API server 的 
API 时 会 被 拒绝 ，web 中 提示 : 


Forbidden (403) 


User "system:serviceaccount:kube-system:default" cannot list job 
s.batch in the namespace "default". (get jobs.batch) 


增加 了 一 个 dashboard-rbac.yaml 文件 ， 定 义 一 个 名 为 dashboard 的 
ServiceAccount， 然 后 将 它 和 Cluster Role view 绑 定 ， 如 下 : 


apiVersion: v1 
kind: ServiceAccount 
metadata: 
name: dashboard 
namespace: kube-system 
kind: ClusterRoleBinding 
apiVersion: rbac.authorization.k8s.io/vibeta1 
metadata: 
name: dashboard 
subjects: 
- kind: ServiceAccount 
name: dashboard 
namespace: kube-system 
roleRef : 
kind: ClusterRole 
name: cluster-admin 
apiGroup: rbac.authorization.k8s.io 


然后 使 用 kubectl apply -f dashboard-rbac.yaml 创建 。 


配置 dashboard-service 


$ diff dashboard-service.yaml.orig dashboard-service.yaml 
10a11 
> type: NodePort 


e 指定 端口 类 型 为 NodePort， 这 样 外 界 可 以 通过 地 址 nodelP:nodePort 访问 
dashboard : 


Ac. à dashboard-controller 


$ diff dashboard-controller.yaml.orig dashboard-controller.yaml 
23c23 


= image: gcr.io/google containers/kubernetes-dashboard-a 
md64:v1.6.0 
> image: harbor-001.jimmysong.io/library/kubernetes-dash 


board-amd64:v1.6.0 


执行 所 有 定义 文件 


$ pwd 

/root/kubernetes/cluster/addons/dashboard 

$ ls *.yaml 

dashboard-controller.yaml  dashboard-service.yaml 
$ kubectl create -f 

service "kubernetes-dashboard" created 

deployment "kubernetes-dashboard" created 


检查 执行 结果 
查看 分 配 的 NodePort 


$ kubectl get services kubernetes-dashboard -n kube-system 


NAME CLUSTER-IP EXTERNAL - IP PORT(S) 
AGE 

kubernetes-dashboard 10.254.224.130 «nodes» 80:30312/T 

CP 25S 


e NodePort 303129 41 2] dashboard pod 803% 7 ; 


检查 controller 


$ kubectl get deployment kubernetes-dashboard -n kube-system 


NAME DESIRED CURRENT UP-TO-DATE AVAILABL 
E AGE 
kubernetes-dashboard 1 1 1 1 
3m 
$ kubectl get pods -n kube-system | grep dashboard 
kubernetes - dashboard - 1339745653 - pmn6z 1/1 Running 0 
4m 


1% l dashboard 
有 以 下 三 种 方式 : 


e kubernetes-dashboard 服务 暴露 了 NodePort， 可 以 使 用 
http://NodeIP:nodePort 地 址 访问 dashboard 

过 API server 访问 dashboard (https 6443 端 口 和 http 8080 端 口 方式 ) 

过 kubectl proxy 访问 dashboard 


e iü 
e i 


` 


通过 kubectl proxy 访问 dashboard 
启动 代理 


$ kubectl proxy --address='172.20.0.113' --port=8086 --accept-ho 
sts='A*$' 
Starting to serve on 172.20.0.113:8086 


e 需要 指定 --accept-hosts 选项 ， 否 则 浏览 器 访问 dashboard 页 面 时 提示 
“Unauthorized” ; 


浏览 器 访问 URL : http://172.20.0.113:8086/ui 自动 跳 转 
到 : http://172.20.0.113:8086/api/v1/proxy/namespaces/kube- 
system/services/kubernetes-dashboard/#/workload?namespace=default 


id x API server ù% "dashboard 
获取 集群 服务 地 址 列表 


$ kubectl cluster-info 

Kubernetes master is running at https://172.20.0.113:6443 
KubeDNS is running at https://172.20.0.113:6443/api/v1/proxy/nam 
espaces/kube-system/services/kube-dns 

kubernetes-dashboard is running at https://172.20.0.113:6443/api 
/V1/proxy/namespaces/kube-system/services/kubernetes-dashboard 


浏览 器 访问 URL : https://172.20.0.113:6443/api/v1/proxy/namespaces/kube- 
system/services/kubernetes-dashboard (浏览 器 会 提示 证书 验证 ， 因 为 通过 加 密 通 
道 ， 以 改 方式 访问 的 话 ， 需 要 提前 导入 证 书 到 你 的 计算 机 中 ) 。 这 是 我 当时 在 这 遇 
到 的 坑 : 通过 kube-apiserver 访问 dashboard， 提 示 User "system:anonymous" 
cannot proxy services in the namespace "kube-system'".#5， 已 经 解决 。 


导入 十 书 
将 生成 的 admin.pem 证 书 转换 格式 


openssl pkcs12 -export -in admin.pem -out admin.p12 -inkey admi 
n-key.pem 





将 生成 的 admin.pi2 证 书 导入 的 你 的 电脑 ， 导 出 的 时 候 记 住 你 设置 的 密码 ， 导 入 
的 时 候 还 要 用 到 。 


如 果 你 不 想 使 用 https 的 话 ， 可 以 直接 访问 insecure port 8080 端 
Uu : http://172.20.0.113:8080/api/v1/proxy/namespaces/kube- 
system/services/kubernetes-dashboard 





三 kubernetes / > Namespaces > kube-system + CREATE 
Admin 
Details 
Namespaces 
Nodes Name: kube-system 
Persistent Volumes Creation time: 2017-04-11T11:20 
Storage Classes Status: Active 
Namespace 
defaut — - Events 
Workload Message Source Sub-object Count First seen Last seen 
Killing container with id docker://c857a 
Deployments 23eb359fb5f46c080b0404f41731d7be spec.containers{kubernetes- 
.20.0.1 1 -04-12T06:51 UT! 17-04- i: 
. 47d0729eb1e5ae9d8b2be123d5f:Need kubelet 172.20.0.114 dashboard) 1 2017-04-12T06:51 UTC 2017-04-12T06:51 UTC 
Replica Sets 
to kill Pod 
Replication Controllers 
Deleted pod: kubernetes-dashboard-17 " " , 
DANSES 52429380-7vkOt replicaset-controller 1 2017-04-12T06:51 UTC 2017-04-12T06:51 UTC 
Stateful Sets Successfully assigned kubernetes-das 
hboard-3966630548-61b48 to 172.20. default-scheduler = 1 2017-04-12T06:56 UTC 2017-04-12T06:56 UTC 
Jobs 0.113 
Pods Container image "sz-pg-oam-docker-hu 
b-001.tendcloud.com/library/kubernete spec.containers{kubernetes- 
s i kubelet 172.20.0.113 1 2017-04-12T06:57 UTC 2017-04-12T06:57 UTC 
Services and discovery s-dashboard-amd64:v1.6.0" already pre uitis dashboard) 
sent on machine 
Services 
Created container with id c36e4cc8e11 spec.containers(kubernetes- 
Ingresses 08805a34affd872449442a3bf628466b — kubelet 172.20.0.113 pE 1 2017-04-12T06:57 UTC 2017-04-12T06:57 UTC 
dashboard) 
8ea2da3c99caf1d7cec23 
Storage x p 
Started container with id c36e4cc8e11 spec.containers{kubernetes 
Bare a 08805a34affd872449442a3bf628466b — kubelet 172.20.0.113 dashboard 1 2017-04-12T06:57 UTC 2017-04-12T06:57 UTC 
8ea2da3c99caf1d7cec23 
Config A Error creating: pods "kubernetes-dashb 
oard-3966630548-" is forbidden: servic 
Secrets a annniint Luhecuctam /dachhnard wae ranlinaeat-nnntrallar A a 9017-04-12T0&-&& ITO 9017.04.12 TR&-&& LITO 


图 片 - kubernetes dashboard 


由 于 缺少 Heapster 插件 ， 当 前 dashboard 不 能 展示 Pod ^ Nodes 的 CPU、 内 存 
等 metric 图 形 。 


更 新 


Kubernetes 1.6 版 本 的 dashboard 的 镜像 已 经 到 了 v1.6.3 版 本 ， 我 们 可 以 使 用 下 
面 的 方式 更 新 。 


修改 dashboard-controller.yaml 文件 中 的 镜像 的 版 本 将 v1.6.0 更 改 为 
v1.6.3 ° 





image: harbor-001.jimmysong.io/library/kubernetes- dashboard -amd64 
:V1.6.3 


E _ 








然后 执行 下 面 的 命令 : 


kubectl apply -f dashboard-controller.yaml 


即 可 在 线 更 新 dashboard 的 版 本 。 


监听 dashboard Pod 的 状态 可 以 看 到 : 


kubernetes-dashboard-215087767-2jsgd 0/1 Pending 0 
ms C ——Ü 1/1 Terminating 
r—— ——À 0/1 Pending 0 
ra e e cesee-094a2 1/1 Terminating 
E a AT ETET 0/1 ContainerCreati 
ng 0 0S 

kubernetes-dashboard-3966630548-0jj1j 0/1 Terminating 
Tiber neces —— HE" 0/1 Terminating 
E 1/1 Running 0 
T —— € 0/1 Terminating 
A EE —— — 0/1 Terminating 
kubernetes-dashboard-3060930549-0j11 0/1 Terminating 
0 1 


新 的 Pod 的 启动 了 ， 昌 的 Pod RAAT © 


Dashboard 的 访问 地 址 不 变 ， 重 新 访问 
http://172.20.0.113:8080/api/v1/proxy/namespaces/kube- 
system/services/kubernetes-dashboard， 可 以 看 到 新 版 的 界面 : 


Q Search + 创建 











节点 
集群 
CPU 使 用 率 内 存 使 用 率 @ 
命名 空间 
节点 1.01 46.1 Gi 
T 0.900 410 Gi 
持久 化 存储 卷 = 
g 0675) Ẹ oza 
角色 g 0.450 g 20.5 Gi 
$ 
存储 类 0.225 E 10.26 
Sar 15:40 15:43 15:46 15:50 15:51 18:37 15:40 15:43 15:46 15:50 15:51 
时 间 时 间 
default ~ 
Overview 节点 = 
工作 负载 名 称 人 标签 CPU 请 求 值 ( 核 ) 核 ) 内 存 请 求 值 (FP) 内 存 限 制 值 (F 已 创建 + 
守护 进程 集 beta.kubernetes.io/arch: a... 
部 署 beta.kubernetes.io/fluentd.. 
任务 @ 172200114 beta kubernetes io/os:linux True 0.4 (1.00%) 2.2 (5.50%) 476 Mi (0.37%) 2.725 Gi (2.17%) 6A 
"aH edgenode: true 
5 kubernetes.io/hostname: 1... 
副本 集 
beta.kubernetes.io/arch: a 
副本 控制 器 
beta.kubernetes.io/fluentd.. 
有 状态 副本 集 > 
@ 172.20.0.115 beta.kubernetes.io/os: linux — True 0.76 (1.90%) 1.4 (3.50%) 1.371 Gi (1.09%) 2.439 Gi (1.94%) 6A 
服务 发 现 与 负载 均衡 edgenode: true 
访问 权 kubernetes.io/hostname: 1... 
服务 beta.kubernetes.io/arch: a. 
beta.kubernetes.io/fluentd... 
KNSHM beta.kubernetes.io/os: linux 
© 172.20.0.113 True 0.4 (1.00%) 2.2 (5.50%) 1.215 Gi (0.97%) 2.225 Gi (1.77%) 6H 
配置 集 edgenode: true 
持久 化 存储 卷 索取 fabric8.io/externallP: true 
保密 字典 显示 所 有 标签 


图 片 - V1.6.3 版 本 的 qashboard 界 面 


新 版 本 中 最 大 的 变化 是 增加 了 进入 容器 内 部 的 入 口 ， 可 以 在 页 面 上 进入 到 容器 内 部 
操作 ， 同 时 又 增加 了 一 个 搜索 框 。 


关于 如 何 将 dashboard 从 1.6 版 本 升级 到 1.7 版 本 请 参考 升级 dashboard 。 


1. 按照 教程 安装 后 ， 发 现 dashboard pod 无 法 启动 


kubectl -n kube-system describe pod dashboard-xxxxxxx 


Mou! 


ulling pulling in 


warning jnc Error 
warning Back- rting failed co 





图 片 - pod 无 法 正常 启动 


"T VA ZAM SPT A d8 X" IR” FE IA— 2K » d» : secret ^ serviceaccount ` 
service ` pod ` deployment 


e WebUl(Dashboard) 文档 
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zc heapsterdé fF 


准备 镜像 
官方 镜像 保存 在 gerio 中 需要 翻 墙 才 能 下 载 ， 为 了 方便 大 家 使 用 ， 我 下 载 后 放 到 了 
速 云 中 ， 为 公有 镜像 供 大 家 下 载 。 


e index.tenxcloud.com/jimmy/heapster-amd64:v1.3.0-beta.1 
e index.tenxcloud.com/jimmy/heapster-influxdb-amd64:v1.1.1 
e index.tenxcloud.com/jimmy/heapster-grafana-amd64:v4.0.2 


AE & YAML x 1T 
到 heapster release 页 面 下 载 最 新 版 本 的 heapster 。 


wget https://github.com/kubernetes/heapster/archive/v1.3.0.zip 
unzip v1.3.0.zip 
mv v1.3.0.zip heapster-1.3.0 


文件 目录 : heapster-1.3.0/deploy/kube-config/influxdb 


$ cd heapster-1.3.0/deploy/kube-config/influxdb 

$ ls *.yaml 

grafana-deployment.yaml  grafana-service.yaml  heapster-deployme 
nt.yaml heapster-service.yaml influxdb-deployment.yaml influx 
db-service.yaml heapster-rbac.yaml 


我 们 自己 创建 了 heapster 的 rbac 配 置 heapster-rbac.yaml 。 


已 经 修改 好 的 yaml 文件 见 : ../manifests/heapster 


配置 grafana-deployment 


$ diff grafana-deployment.yaml.orig grafana-deployment.yaml 
16c16 


« image: gcr.io/google containers/heapster-grafana-amd64 
:V4.0.2 

> image: harbor-001.jimmysong.io/library/heapster-grafan 
a-amd64:v4.0.2 

40, 41c40, 41 

« 4 value: /api/vi/proxy/namespaces/kube-system/servic 
es/monitoring-grafana/ 

< value: / 

> value: /api/v1/proxy/namespaces/kube-system/services 
/monitoring- r 

> #value: / 


e 如 果 后 续 使 用 kube-apiserver 或 者 kubectl proxy 访问 grafana dashboard > Ji] 
必须 将 GF SERVER ROOT URL 设置 为 /api/vi/proxy/namespaces/kube- 
system/services/monitoring-grafana/ ， 否 则 后 续 访 问 grafana 时 访问 时 
提示 找 不 到 http://172.20.0.113:8086/api/v1/proxy/namespaces/kube- 


system/services/monitoring-grafana/api/dashboards/home 页 面 ; 


配置 heapster-deployment 


$ diff heapster-deployment.yaml.orig heapster-deployment.yaml 
16c16 


« image: gcr.io/google containers/heapster-amd64:v1.3.0- 
beta.1 
> image: harbor-001.jimmysong.io/library/heapster-amd64: 


v1.3.0-beta.1 


配置 influxdb-deployment 


influxdb 官方 建议 使 用 命令 行 或 HTTP API 接口 来 查询 数据 库 ， 从 v1.1.0 版 本 开始 
默认 关闭 admin U1， 将 在 后 续 版 本 中 移 除 admin UI 插件。 


局 镜像 中 admin UI 的 办 法 如 下 : 先导 出 镜像 中 的 influxdb 配置 文件 ， 开 启 admin 
eae 再 将 配置 文件 内 容 写 入 ConfigMap > RERA SRP > 38 81 BIR 4 S6 
置 的 目的 : 


注意 : manifests 目录 已 经 提供 了 修改 后 的 ConfigMap 定义 文件 


$ # 导出 镜像 中 的 influxdb 配置 文件 

$ docker run --rm --entrypoint 'cat' -ti lvanneo/heapster-influ 
xdb-amd64:v1.1.1 /etc/config.toml >config.toml.orig 

$ cp config. toml.orig config.toml 

$ # 修改 :启用 admin 接口 

$ vim config.toml 

$ diff config.toml.orig config.toml 

35c35 

« enabled - false 

> enabled = true 

$ 4 将 修改 后 的 配置 写 入 到 ConfigMap 3t% P 

$ kubectl create configmap influxdb-config --from-file=config.to 
ml -n kube-system 

configmap "influxdb-config" created 

$ 4 X ConfigMap 中 的 配置 文件 挂 载 到 Pod 中 ， 达 到 敌 盖 原始 配置 的 目的 

$ diff influxdb-deployment.yaml.orig influxdb-deployment.yaml 
16c16 


< image: gcr.io/google containers/heapster-influxdb-amd6 
4:V1.1.1 

> image: harbor-001.jimmysong.io/library/heapster - influx 
db-amd64:vi.1.1 

19a20, 21 

> - mountPath: /etc/ 

> name: influxdb-config 

22a25, 27 

> - name: influxdb-config 

> configMap: 

> name: influxdb-config 


配置 monitoring-influxdb Service 


$ diff influxdb-service.yaml.orig influxdb-service.yaml 
12a13 
> type: NodePort 


15a17, 20 

> name: http 

> - port: 8083 

> targetPort: 8083 
> name: admin 


e 定义 端口 类 型 为 NodePort， 人 额外 增加 了 admin 端口 映射 ， 用 于 后 续 浏 览 器 访 
问 influxdb 的 admin UI 界面; 


执行 所 有 定义 文件 


$ pwd 

/root/heapster-1.3.0/deploy/kube-config/influxdb 

$ ls *.yaml 

grafana-service.yaml heapster-rbac.yaml influxdb-cm.yam 
l influxdb-service.yaml 

grafana-deployment.yaml  heapster-deployment.yaml  heapster-serv 
ice.yaml  influxdb-deployment.yaml 

$ kubectl create -f 

deployment "monitoring-grafana" created 

service "monitoring-grafana" created 

deployment "heapster" created 

serviceaccount "heapster" created 

clusterrolebinding "heapster" created 

service "heapster" created 

configmap "influxdb-config" created 

deployment "monitoring-influxdb" created 

service "monitoring-influxdb" created 


检查 执行 结果 
检查 Deployment 


$ kubectl get deployments -n kube-system | grep -E 'heapster |mon 
itoring' 
heapster 1 1 1 1 
2m 
monitoring-grafana 1 1 1 1 
2m 
monitoring-influxdb 1 1 1 1 
2m 


检查 Pods 


$ kubectl get pods -n kube-system | grep -E 'heapster|monitoring' 


heapster-110704576-gpg8v 1/1 Running 0 
2m 

monitoring-grafana-2861879979-9z289f 1/1 Running 0 
2m 

monitoring-influxdb-1411048194-1zrpc 1/1 Running 0 
2m 


E E mE uj 








< heapster 


检查 kubernets dashboard 界面 ， 看 是 显示 各 Nodes ^ Pods 的 CPU ^ Zr ^ fi d 


等 利用 率 曲 线 图 ; 


+ CREATE 





三 kubernetes Workloads > Deployments 
Admin 
CPU usage 
Namespaces 
Nodes 0.001 


Persistent Volumes 


Storage Classes 


CPU (cores) 
ooo 
S 
8 
8 
8 


0003 

Namespace 18:58 19:58 

default 
Workloads 

Deployments 
Deployments 
3 Name Labels 
Replica Sets 
Replication Controllers © my-nginx run: my-nginx 


Daemon Sets 
Stateful Sets 
Jobs 
Pods 
Services and discovery 


Services 


Ingresses 
Storage 

Persistent Volume Claims 
Config 


Secrets 


Memory usage @ 


19.3 Mi 
g 17.2 Mi 
Š 12.9 Mi 
E 8.58 Mi 
5 4.29 Mi 
i 
18:57 19:57 19:58 19:59 
Time 
Age Images 
7 hours sz-pg-oam-docker-hub-001.tendclo.. 


图 片 - dashboard-heapster 


功 问 grafana 


1. 通过 kube-apiserver 访问 : 


获取 monitoring-grafana 服务 URL 


ï] 


$ kubectl cluster-info 

Kubernetes master is running at https://172.20.0.113:6443 
Heapster is running at https://172.20.0.113:6443/api/v1/pro 
xy/namespaces/kube-system/services/heapster 

KubeDNS is running at https://172.20.0.113:6443/api/vi/prox 
y/namespaces/kube-system/services/kube-dns 
kubernetes-dashboard is running at https://172.20.0.113:644 
3/api/vi/proxy/namespaces/kube-system/services/kubernetes-da 
shboard 

monitoring-grafana is running at https://172.20.0.113:6443/ 
api/vi/proxy/namespaces/kube-system/services/monitoring-graf 
ana 

monitoring-influxdb is running at https://172.20.0.113:6443 
/api/vi/proxy/namespaces/kube-system/services/monitoring- inf 
luxdb 


To further debug and diagnose cluster problems, use 'kubect 
l cluster-info dump'. 


览 器 访问 URL: 


http://172.20.0.113:8080/api/v1/proxy/namespaces/kube- 
system/services/monitoring-grafana 


通 


创 


浏 


过 kubectl proxy 访问 : 
建 代理 
$ kubectl proxy --address='172.20.0.113' --port=8086 --acce 


pt-hosts='4*$' 
Starting to serve on 172.20.0.113:8086 


Ww SR 


览 器 访问 


URL: http://172.20.0.113:8086/api/v1/proxy/namespaces/kube - 
system/services/monitoring-grafana 


X49 - ”网 Cluster - ooi © Last30 minutes © 


nodename 172.20.0.113 ~ 


Overall Cluster CPU Usage 


19:32 19:34 19:44 19:46 


Usage — Limit 一 Request 


CPU Usage by Node 


19:32 19:34 19:36 19:38 19:40 19:42 19:44 19:46 19:48 19:50 19:52 19:54 19:56 
Usage 172.20.0.113 一 Usage 172.20.0.114 一 Usage 172.20.0.115 Limit 172.20.0.113 Limit 172.20.0.114 Limit 172.20.0.115 Request 172.20.0.113 Request 172.20.0.114 Request 172.20.0.115 


Individual CPU Usage: 172.20.0.113 





E HA - grafana 


i3 |*] influxdb admin UI 
获取 influxdb http 8086 映射 的 NodePort 


$ kubectl get svc -n kube-system|grep influxdb 
monitoring-influxdb 10.254.22.46 «nodes» 8086:32299/ 
TCP,8083:30269/TCP 9m 


通过 kube-apiserver 的 非 安 全 端口 访问 influxdb 的 admin UI 界面 : 
http://172.20.0.113:8080/api/v1/proxy/namespaces/kube- 
system/services/monitoring-influxdb:8083/ 


Æ ft 49 "Connection Settings" 的 Host 中 输入 node IP * Port 中 输入 8086 映射 
的 nodePort 如 上 面 的 32299 > Ad "Save" PPT (我 的 集群 中 的 地 址 是 
172.20.0.113:32299 ) 


Influx Write Data Jocumentation Database: intemal ~ — X 





Query: SHOW STATS 


Generate Query URL Query Templates ~ 


Alloc Frees HeapAlloc Heapldle  HeaplnUse HeapObjects HeapReleased HeapSys Lookups Mallocs NumGC  NumGoroutine PauseTotalNs Sys TotalAlloc 
23863080 1218254 23863080 23699456 24633344 59978 0 48332800 325 1278232 15 36 7932812 60901624 175351688 


queryExecutor 


queriesActive queriesExecuted queriesFinished queryDurationNs 
1 59 58 253464302 
abase: internal, engine:tsm1, id:1, path:/data/data/_internal/monitor/1, retentionPolicy:monitor, walPath:/data/wal/_internal/monitor/1 
diskBytes fieldsCreate seriesCreate writeBytes writePointsDropped writePointsErr writePointsOk writeReq writeReqErr writeReqOk 
193635 101 18 0 0 0 1074 64 0 64 


tsm1 engine 


m1, id:1, path:/data/data/_internal/monitor/1, retentionPolicy:monitor, walPath:/data/wal/ 





cacheCompactionDuration cacheCompactionErr cacheCompactions cacheCompactionsActive tsmFullCompactionDuration tsmFullCompactionErr tsmFullCompactions tsmFullComr 


0 0 0 0 0 0 0 0 


tsm1 -cache 


latabase: internal, engine:tsm1, id:1, path:/data/data/_internal/monitor/1, retentionPolicy:monitor, walPath:/data/wal/_internal/monitor/1 





E A - kubernetes-influxdb-heapster 


在 安装 好 Grafana 之 后 我 们 使 用 的 是 默认 的 template 配置 ， 页 面 上 的 namespace 
选择 里 只 有 default 和 kube-system ， 并 不 是 说 其 他 的 namespace 里 的 指标 
没有 得 到 监控 ， 只 是 我 们 没有 在 Grafana 中 开启 他 它们 的 显示 而 已 。 见 Cannot 

see other namespaces except, kube-system and default #1279 ° 


Value groups/tags (Experimental feature) 





EA - 修改 grafana 模 板 


将 Templating 中 的 namespace 的 Data source 设置 为 influxdb-datasource ， 
Refresh 设置 为 on Dashboard Load 保存 设置 ， 刷 新 浏览 器 ， 即 可 看 到 其 他 
namespace 选项 。 


参考 


使 用 Heapster 获 取 集 群 对 象 的 metric 数 据 
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eR EFK AG t 


我 们 通过 在 每 台 node 上 部 署 一 个 以 DaemonSet 方 式 运行 的 fuentd 来 收集 每 台 node 

上 的 日 志 。Fluentd 将 docker 日 志 目 

i /var/lib/docker/containers 和 /var/log 目录 挂 载 到 Pod 中 ， 然 后 Pod 会 

在 node 节 点 的 /var/log/pods 目录 中 创建 新 的 目录 ， 可 以 区 别 不 同 的 容器 日 志 输 
出 ， 该 目录 下 有 一 个 日 志文 件 链接 到 /var/lib/docker/contianers 目录 下 的 容 


只 


器 日 志 输 出 。 


官方 文件 目录 : cluster/addons/fluentd-elasticsearch 


$ ls *.yaml 
es-controller.yaml es-service.yaml fluentd-es-ds.yaml  kibana- 
controller.yaml  kibana-service.yaml efk-rbac.yaml 


同样 EFK 服 务 也 需要 一 个 efk-rbac.yaml 文件 ， 配 置 Serviceaccount 为 efk ° 


已 经 修改 好 的 yam 文件 见 : ../manifests/EFK 


配置 es-controlleryaml 


$ diff es-controller.yaml.orig es-controller.yaml 


24c24 

< - image: gcr.io/google containers/elasticsearch:v2.4.1-2 
> - image: harbor-001.jimmysong.io/library/elasticsearch:v 
2.4.1-2 


Ac es-service.yaml 


无 需 配置 ; 


配置 fluentd-es-ds.yaml 


$ diff fluentd-es-ds.yaml.orig fluentd-es-ds.yaml 


26c26 

< image: gcr.io/google containers/fluentd-elasticsearch: 
1.22 

> image: harbor-001.jimmysong.io/library/fluentd-elastic 
search:1.22 


配置 kibana-controller.yaml 


$ diff kibana-controller.yaml.orig kibana-controller.yaml 
22C22 
< image: gcr.io/google containers/kibana:v4.6.1-1 


> image: harbor-001.jimmysong.io/library/kibana:v4.6.1-1 


给 Node 设置 标签 


定义 DaemonSet fluentd-es-vi.22 时 设置 了 nodeSelector 
beta.kubernetes.io/fluentd-ds-ready-true ， 所 以 需要 在 期 望 运行 fluentd 
的 Node 上 设置 该 标签 ; 


$ kubectl get nodes 
NAME STATUS AGE VERSION 
172.20.0.113 Ready 1d v1.6.0 


$ kubectl label nodes 172.20.0.113 beta.kubernetes.io/fluentd-ds 
-ready-true 
node "172.20.0.113" labeled 


给 其 他 两 台 node 打 上 同样 的 标签 。 


执行 定义 文件 


$ kubectl create -f . 

serviceaccount "efk" created 

clusterrolebinding "efk" created 

replicationcontroller "elasticsearch-logging-vi" created 
service "elasticsearch-logging" created 

daemonset "fluentd-es-v1.22" created 

deployment "kibana-logging" created 

service "kibana-logging" created 


检查 执行 结果 


$ kubectl get deployment -n kube-system|grep kibana 
kibana-logging 1 1 1 1 
2m 


$ kubectl get pods -n kube-system|grep -E 'elasticsearch|fluentd 


| kibana' 

elasticsearch-logging-vi-mlstp 1/1 Running 0 
ieee ae ee nee 1/1 Running 0 
uenti eee 1/1 Running 0 
ET ee E 1/1 Running 0 
EIUS eer 1/1 Running 0 
人 1/1 Running 0 

1m 


$ kubectl get service -n kube-system|grep -E 'elasticsearch|kib 

ana' 

elasticsearch-logging 10.254.77.62 «none» 9200/TCP 
2m 

kibana-logging 10.254.8.113 «none» 5601/TCP 
2m 


kibana Pod 第 一 次 启动 时 会 用 较 长 时 间 (10-20 分 钟 ) 来 优化 和 Cache KAR D> T 
以 tailf 该 Pod 的 日 志 观 察 进度 : 


$ kubectl logs kibana-logging-1432287342-Ogdng -n kube-system -f 
ELASTICSEARCH URL-http://elasticsearch-logging:9200 
server.basePath: /api/v1/proxy/namespaces/kube-system/services/k 
ibana-logging 
("type":"log","Qtimestamp":"2017-04-12T13:08:06Z2", "tags" : ["info", 
"optimize"],"pid":7,"message":"Optimizing and caching bundles fo 


安装 EFK 插 件 


r kibana and statusPage. This may take a few minutes"} 
{"type": "log", "@timestamp":"2017-04-12T13:18:172Z", "tags": ["info", 
"optimize"],"pid":7,"message":"Optimization of bundles for kiban 
a and statusPage complete in 610.40 seconds"} 
("type":"1og","Qtimestamp":"2017-04-12T13:18:17Z", tags": ["statu 
s","plugin:kibanaQ1.0.0","info"],"pid":7,"'state":"green', "messag 
e":"Status changed from uninitialized to green - Ready'","prevSta 
te":"uninitialized","prevMsg":"uninitialized") 
("type":"1og","Qtimestamp":"2017-04-12T13:18:18Z", "tags": ["statu 
s","plugin:elasticsearch@1.0.0","info"],"pid":7,"state":"yellow", 
"message":"Status changed from uninitialized to yellow - Waiting 
for Elasticsearch", "prevState": "uninitialized", "prevMsg":"unini 
tialized"} 
("type":"1og","Qtimestamp":"2017-04-12T13:18:19Z", "tags": ["statu 
s", "plugin: kbn_vislib_vis_types@1.0.0","info"],"pid":7,"state":" 
green", "message": "Status changed from uninitialized to green - R 
eady", "prevState": "uninitialized", "prevMsg":"uninitialized"} 
("type":"1og","Qtimestamp":"2017-04-12T13:18:19Z", "tags": ["statu 
s","plugin:markdown visQ1.0.0","info"],"pid":7," 'state":"green"," 
message":"Status changed from uninitialized to green - Ready","p 
revState":"uninitialized", "prevMsg":"uninitialized"} 
("type":"1og","Qtimestamp":"2017-04-12T13:18:19Z", tags": ["statu 
s","plugin:metric visQ1.0.0","info"],"pid":7,"state":"green", "me 
ssage":"Status changed from uninitialized to green - Ready","pre 
vState":"uninitialized"," "prevMsg":"uninitialized") 
("type":"1og","Qtimestamp":"2017-04-12T13:18:19Z", tags": ["statu 
s","plugin:spyModesQ1.0.0","info"],"pid":7,"state":"green", "mess 
age":"Status changed from uninitialized to green - Ready","prevS 
tate": "uninitialized", "prevMsg": "uninitialized"} 
{"type": "log", "@timestamp": "2017 -04-12T13:18:192Z", "tags": ["statu 
s", "plugin: statusPage@1.0.0", "info"],"pid":7, "state": "green", "me 
ssage":"Status changed from uninitialized to green - Ready", "pre 
vState": "uninitialized", "prevMsg":"uninitialized"} 
{"type": "log", "@timestamp":"2017-04-12T13:18:19Z", "tags": ["statu 
s","plugin:table visQ1.0.0","info"],"pid":7,"state":"green", "mes 
sage":"Status changed from uninitialized to green - Ready", "prev 
State": "uninitialized", "prevMsg":"uninitialized"} 
{"type": "log", "@timestamp":"2017-04-12T13:18:192", "tags": ["liste 
ning","info"],"pid":7, "message": "Server running at http://0.0.0. 
0:5601"} 
{"type": "log", "@timestamp":"2017-04-12T13:18:24Z", "tags": ["statu 
s", "plugin: elasticsearch@1.0.0","info"],"pid":7,"state":"yellow", 
"message":"Status changed from yellow to yellow - No existing Ki 
bana index found", "prevState": "yellow", "prevMsg": "Waiting for El 
asticsearch"} 
{"type": "log", "@timestamp":"2017-04-12T13:18:29Z","tags":["statu 
s", "plugin:elasticsearch@1.0.0","info"],"pid":7,"state":"green", 
"message":"Status changed from yellow to green - Kibana index re 
ady", "prevState": "yellow", "prevMsg":"No existing Kibana index fo 
und"? 


i —————————————(-——À—sÓo ni 
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通过 kube-apiserver 访问 : 


获取 monitoring-grafana 服务 URL 


$ kubectl cluster-info 

Kubernetes master is running at https://172.20.0.113:6443 
Elasticsearch is running at https://172.20.0.113:6443/api/v 
1/proxy/namespaces/kube-system/services/elasticsearch-loggin 
9 

Heapster is running at https://172.20.0.113:6443/api/v1/pro 
xy/namespaces/kube-system/services/heapster 

Kibana is running at https://172.20.0.113:6443/api/v1/proxy 
/namespaces/kube-system/services/kibana-logging 

KubeDNS is running at https://172.20.0.113:6443/api/vi/prox 
y/namespaces/kube-system/services/kube-dns 
kubernetes-dashboard is running at https://172.20.0.113:644 
3/api/v1/proxy/namespaces/kube-system/services/kubernetes-da 
shboard 

monitoring-grafana is running at https://172.20.0.113:6443/ 
api/vi/proxy/namespaces/kube-system/services/monitoring-graf 
ana 

monitoring-influxdb is running at https://172.20.0.113:6443 
/api/vi/proxy/namespaces/kube-system/services/monitoring- inf 
luxdb 


浏览 器 访问 URL: 


https://172.20.0.113:6443/api/v1/proxy/namespaces/kube- 


system/services/kibana-logging/app/kibana 
通过 kubectl proxy 访问 : 


创建 代理 


$ kubectl proxy --address='172.20.0.113' --port=8086 --acce 
pt-hosts-'^*$' 
Starting to serve on 172.20.0.113:8086 


Ww SR 


浏览 器 访问 
URL: http://172.20.0.113:8086/api/v1/proxy/namespaces/kube - 
system/services/kibana-logging 


在 Settings -> Indices 页 面 创建 一 个 index (相当 于 mysql ? 4j —^ database) > 
选中 Index contains time-based events ， 使 用 默认 的 logstash-* 
pattern， 点 击 Create ; 


可 能 遇 到 的 问题 


如 果 你 在 这 里 发 现 Create 按 钮 是 灰色 的 无 法 点 击 ， 且 Time-filed name 中 没有 选项 ， 
fluentd 要 读 取 /var/log/containers/ 目录 下 的 |log 日 志 ， 这 些 日 志 是 

从 /var/lib/docker/containers/${CONTAINER_ID}/${CONTAINER_ID}- 
json.log 链接 过 来 的 ， 查 看 你 的 docker 配 置 ， —log-dirver 需要 设置 为 json- 
file 格 式 ， 上 默认 的 可 能 是 journald， 参 考 docker logging ° 


| o an rs | Discover Visualize Dashboard Settings 


Indices Advanced Objects Status About 





Index Patterns 

No default index C fi 1 d 

pattern. You must select or create on Ig u re an l n ex pattern 

CHONDA In order to use Kibana you must configure at least one index pattern. Index patterns are used to identify the Elasticsearch index to run search and analytics against. They are also 
used to configure fields. 


Index contains time-based events 
Use event times to create index names [DEPRECATED] 


Index name or pattern 
Patterns allow you to define dynamic index names using * as a wildcard. Example: logstash-* 
logstash-* 


~ Do not expand index pattern when searching (Not recommended) 


By default, searches against any time-based index pattern that contains a wildcard will automatically be expanded to query only the indices that contain data within the 
currently selected time range. 


Searching against the index pattern /ogstash-* will actually query elasticsearch for the specific matching indices (e.g. logstash-2015. 12.21) that fall within the current time 
range. 


Time-field name € refresh fields 


Gtimestamp $ 


图 片 - es-setting 


创建 Index 后 ， 可 以 在 Discover 下 看 到 ElasticSearch logging 中 汇聚 的 日 志 ; 


ere] are! 





Selected Fields 


Available Fields 
@timestamp 
id 
_index 
_score 
-type 
docker.container_id 
kubernetes.container_name 
kubernetes. host, 
kubernetes.labels.k8s-app 
kubernetes.labels.kubernetes_io/clu... 


kubernetes.labels.pod-template-gen... 


Quick Count @ (18 
1 aa 
heuak s 


Visualize (1 warning A) 


kubernetes.labels.pod-template-hash 


kubernetes.labels.task 


Quick Count @ (61 
aa 


monitoring 


Visualize (1 warning A) 


kubernetes.labels.version 
kubernetes.namespace_name 


kubernetes.pod_id 


Discover 


Count 


Visualize Dashboard Settings 


1,024 hits 


April 13th 2017, 11:24:41.684 - April 13th 2017, 11:39:41.684 — by 30 seconds 





800 

600 

400 

200 

oE — m. —ÁÉ| . — (n = m 

11:25:00 11:26:00 11:27:00 11:28:00 11:29:00 11:30:00 11:31:00 11:32:00 11:33:00 11:34:00 11:35:00 11:36:00 11:37:00 11:38:00 11:39:00 
@timestamp per 30 seconds 
a 

Time -source 

April 13th 2017, 11:39:38.000 jog: 10413 03:39:38.462290 1 dns.go:264] New service: elasticsearch-logging stream: stderr docker.container_id: b814e2d9b6b763 
1032a414903a55b513804151b071587020dee62412cc695e52 kubernetes.namespace name: kube-system kubernetes.pod_id: 5a888c58-1f37-1le 
7-9478-f4e9d49f8ed0 kubernetes.pod name: kube-dns-3392212829-93v3t kubernetes.container name: kubedns kubernetes.labels.k8s- 
app: kube-dns kubernetes.labels.pod-template-hash: 3392212829 kubernetes.host: 172.20.0.115 tag: kubernetes.var.log.container 
S.kube-dns-3392212829-93vy3t kube-system kubedns-b814e2d9b56b7631032a414903355b513804151b071587020dee62412cc695e52 . 100 

April 13th 2017, 11:39:38.000 jog: 10413 03:39:38.462451 1 dns.go:462] Added SRV record &[Host:kube-dns.kube-system.svc.cluster.local. Port:53 Priority:10 wei 
ght:10 Text: Mail:false Tt1:30 TargetStrip:0 Group: Key:) stream: stderr docker.container id: b814e2d9b6b7631032a414903a55b5138 
04151b071587020dee62412cc695e52 Kkubernetes.namespace name: kube-system kubernetes.pod id: 5a888c58-1f37-11e7-9478-f4e9d49f8edO 
kubernetes.pod name: kube-dns-3392212829-93v3t kubernetes.container name: kubedns kubernetes.labels.k8s-app: kube-dns 
kubernetes.labels.pod-template-hash: 3392212829 kubernetes.host: 172.20.0.115 tag: kubernetes.var.log.containers.kube-dns-33 

April 13th 2017, 11:39:38.000 jog: 10413 03:39:38.462037 1 dns.go:264] New service: kubernetes-dashboard stream: stderr docker.container id: b814e2d9b6b7631 
032a414903a55b513804151b071587020dee62412cc695e52 kubernetes.namespace name: kube-system kubernetes.pod id: 5a888c58-1f37-11e7 
-9478-f4e9d49f8ed0 kubernetes.pod name: kube-dns-3392212829-93v3t kubernetes.container name: kubedns kubernetes.labels.k8s- 
app: kube-dns kubernetes.labels.pod-template-hash: 3392212829 kubernetes.host: 172.20.0.115 tag: kubernetes.var.log.container 
s. kube-dns-3392212829-93v3t_kube-system_kubedns-b814e2d9b6b7631032a414903a5 5b513804151b071587020dee62412cc695e52. 109 

April 13th 2017, 11:39:38.000 


log: 10413 03:39:38.462554 1 dns.go:264] New service: monitoring-influxdb stream: stderr docker.container_id: b814e2d9b6b76310 


32a414903a55b513804151b071587020dee62412cc695e52 kubernetes.namespace name: kube-system kubernetes.pod_id: 5a888c58-1f37-11e7- 


图 片 - es-home 
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kubeadm 


基本 介绍 


kubeadm 是 一 个 工具 包 ， 可 帮助 您 以 简单 ， 合 理 安全 和 可 扩展 的 方式 引导 最 佳 实 
践 Kubernetes 群 集 。 它 还 支持 为 您 管理 Bootstrap Tokens 并 升级 /降级 群集 。 


kubeadm 的 目标 是 建立 一 个 通过 Kubernetes 一 致 性 测试 Kubernetes Conformance 
tests 的 最 小 可 行 集群 ， 但 不 会 安装 其 他 功能 插件 。 


它 在 设计 上 并 未 为 您 安装 网 络 解决 方案 ， 需 要 用 户 自行 安装 第 三 方 符合 CNI 的 网 络 
解决 方案 (如 flanal > calico ，canal 等 ) ° 


kubeadm 可 以 在 多 种 设备 上 运行 ， quc Oe a ， 虑 拟 机 ， 物 理 / 云 服务 
器 或 Raspberry Pi ° 这 使 得 kubeadm 非 常 适合 与 不 同 种 类 的 配置 系统 (例如 
Terraform ，Ansible 等 ) 集成 。 


kubeadm 是 一 种 简单 的 方式 让 新 用 户 开 始 尝试 Kubernetes， 也 可 能 是 第 一 次 让 现 有 
户 轻 松 测 试 他 们 的 应 用 程序 并 缝合 到 一 起 的 方式 ， 也 可 以 作为 其 他 生态 系统 中 的 
建 块 ， 或 者 具有 更 大 范围 的 安装 工具 。 


可 以 在 支持 安装 deb 或 [rpm 软件 包 的 操作 系统 上 非常 轻松 地 安装 kubeadm 。SIG 集 群 
生命 周期 SIG Cluster Lifecycle kubeadm 的 SIG 相 关 维 护 者 提供 了 预 编译 的 这 些 软 
件 包 ， 也 可 以 在 其 他 操作 系统 上 使 用 。 


kubeadm 成 熟 度 


2X 成 熟 度 Level 

Command line UX beta 

Implementation beta 

Config file API alpha 
Self-hosting alpha 
kubeadm alpha subcommands alpha 
CoreDNS alpha 
DynamicKubeletConfig alpha 


kubeadm 的 整体 功能 状态 为 Beta > BP 172018 年 推 向 General 

Availability (GA) 。 一 些 子 功能 (如 自 托管 或 配置 文件 API) 仍 在 积极 开发 中 。 随 
着 这 个 工具 的 发 展 ， 创 建 集群 的 实现 可 能 会 稍微 改变 ， 但 总 体 实现 应 该 相当 稳定 。 
根据 kubeadm alpha 定义 ， 任 何 命令 都 在 alpha 级 别 上 受 支持 。 


支持 时 间 表 


Kubernetes 版 本 通常 支持 九 个 月 ， 在 此 期 间 ， 如 果 发 现 严重 的 错误 或 安全 问题 ， 可 
能 会 从 发 布 分 支 发 布 补丁 程序 版 本 。 这 里 是 最 新 的 Kubernetes 版 本 和 支持 时 间 表 ; 
这 也 适用 于 kubeadm . 


Kubernetes version Release month End-of-life-month 
v1.6.x March 2017 December 2017 
v1.7.x June 2017 March 2018 
v1.8.x September 2017 June 2018 
v1.9.x December 2017 September 2018 
v1.10.x March 2018 December 2018 
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用 kubeadm 在 Ubuntu 上 快速 构建 Kubernetes 
测试 集群 


本 文 将 介绍 如 何在 Ubuntu server 16.04 版 本 上 安装 kubeadm， 并 利用 kubeadm 快 速 
的 在 Ubuntu server 版 本 16.04 上 构建 一 个 kubernetes 的 基础 的 测试 集群 ， 用 来 做 学 
习 和 测试 用 途 ， 当 前 (2018-04-14) 最 新 的 版 本 是 1.10.1。 参 考 文档 包括 

kubernetes 官 方 网 站 的 kubeadm 安 装 文档 以 及 利用 kubeadm 创 建 集群 这 两 个 文档 。 


生产 用 途 的 环境 ， 需 要 考虑 各 个 组 件 的 高 可 用 ， 建 议 参考 Kubernetes 的 官方 的 相关 
的 安装 文档 。 


概述 


本 次 安装 建议 至 少 4 台 服务 器 或 者 虚拟 机 ， 每 台 服 务 器 4G 内 存 ，2 个 CPU 核 心 以 
上 ， 基 本 架构 为 1 台 master 节 点 ，3 台 slave 节 点 。 整 个 安装 过 程 将 在 Ubuntu 服务 器 
上 安装 完 kubeadm， 以 及 安装 kubernetes 的 基本 集群 ， 包 括 canal 网 络 ， 另 后 台 存 
储 可 参考 本 书 的 最 佳 实践 中 的 存储 管理 内 容 。 本 次 安装 一 共 4 个 节点 ， 节 点 信息 如 
T: 


角色 主机 名 IP 地 址 
Master Ubuntu-master 192.168.5.200 
Slave Ubuntu-1 192.168.5.201 
Slave Ubuntu-2 192.168.5.202 
Slave ubuntu-3 192.168.5.203 


准备 工作 


e 默认 方式 安装 Ubuntu Server 版 本 16.04 
e 配置 主机 名 映射 ， 每 个 节点 


A 
经 


E 


# cat /etc/hosts 

127.0.0.1 localhost 
192.168.0.200 Ubuntu-master 
192.168.0.201 Ubuntu-1 
192.168.0.202 Ubuntu-2 
192.168.0.203 Ubuntu-3 


e 如 果 连 接 gcr 网 站 不 方便 ， 无 法 下 载 镜像 ， 会 导致 安装 过 
出 的 镜像 包 ， 我 导出 的 镜像 网 盘 链 接 ， 解 压缩 以 后 是 
用 docker load< xxxx.tar 导入 各 个 文件 即 可 ) © 


过 程 卡 住 ， 可 以 下 载 我 导 
多 个 个 tar 包 ， 使 


在 所 有 节点 上 安装 kubeadm 
查看 apt 安 装 源 如 下 配置 ， 使 用 阿里 云 的 系统 和 kubernetes 的 源 。 


$ cat EU o apte list 
A 系统 安装 激 


deb Mp 


deb http: 


cted 


deb http: 


deb http 


deb http: 
deb http: 
deb http: 


I ATOE 
//mirrors. 


//mirrors. 
://mirrors 
//mirrors. 


//mirrors 


//mirrors. 


.aliyun. 
aliyun. 


aliyun. 
.aliyun. 
aliyun. 
.aliyun. 
aliyun. 


com/ubuntu/ 
com/ubuntu/ 


com/ubuntu/ 
com/ubuntu/ 
com/ubuntu/ 
com/ubuntu/ 
com/ubuntu/ 


xenial main restricted 
xenial-updates main restri 


xenial universe 
xenial-updates universe 
xenial multiverse 
xenial-updates multiverse 
xenial-backports main rest 


ricted universe multiverse 
# kubeadm 及 kubernetes 组 件 安 装 源 

deb https://mirrors.aliyun.com/kubernetes/apt kubernetes-xenial 
main 


安装 docker， 可 以 使 用 系统 源 的 的 docker.io 软 件 包 
安装 好 最 新 的 版 本 了 。 


， 版 本 1.13.1， 我 的 系统 里 是 已 


# apt-get install docker.io 

Reading package lists... Done 

Building dependency tree 

Reading state information... Done 

docker.io is already the newest version (1.13.1-Oubuntu1-16.04.2) 


© upgraded, © newly installed, © to remove and 4 not upgraded. 








更 新 源 ， 可 以 不 理会 gpg 的 报错 信息 。 


# apt-get update 

Hit:1 http://mirrors.aliyun.com/ubuntu xenial InRelease 

Hit:2 http://mirrors.aliyun.com/ubuntu xenial-updates InRelease 

Hit:3 http://mirrors.aliyun.com/ubuntu xenial-backports InReleas 
e 

Get:4 https://mirrors.aliyun.com/kubernetes/apt kubernetes-xenia 
1 InRelease [8,993 B] 

Ign:4 https://mirrors.aliyun.com/kubernetes/apt kubernetes-xenia 
1 InRelease 

Fetched 8,993 B in Os (20.7 kB/s) 

Reading package lists... Done 

W: GPG error: https://mirrors.aliyun.com/kubernetes/apt kubernet 
es-xenial InRelease: The following signatures couldn't be verifi 
ed because the public key is not available: NO PUBKEY 6A030B21BA 
O7F4FB 

W: The repository 'https://mirrors.aliyun.com/kubernetes/apt kub 
ernetes-xenial InRelease' is not signed. 

N: Data from such a repository can't be authenticated and is the 
refore potentially dangerous to use. 

N: See apt-secure(8) manpage for repository creation and user co 
nfiguration details. 


强制 安装 kubeadm °’ kubectl > kubelet4x fF &, » 


# apt-get install -y kubelet kubeadm kubectl --allow-unauthentic 

ated 

Reading package lists... Done 

Building dependency tree 

Reading state information... Done 

The following additional packages will be installed: 
kubernetes-cni socat 

The following NEW packages will be installed: 
kubeadm kubectl kubelet kubernetes-cni socat 

© upgraded, 5 newly installed, © to remove and 4 not upgraded. 

Need to get 56.9 MB of archives. 

After this operation, 410 MB of additional disk space will be us 

ed. 

WARNING: The following packages cannot be authenticated! 
kubernetes-cni kubelet kubectl kubeadm 

Authentication warning overridden. 

Get:1 http://mirrors.aliyun.com/ubuntu xenial/universe amd64 soc 

at amd64 1.7.3.1-1 [321 kB] 

Get:2 https://mirrors.aliyun.com/kubernetes/apt kubernetes-xenia 

l/main amd64 kubernetes-cni amd64 0.6.0-00 [5,910 kB] 

Get:3 https://mirrors.aliyun.com/kubernetes/apt kubernetes-xenia 

l/main amd64 kubelet amd64 1.10.1-00 [21.1 MB] 

Get:4 https://mirrors.aliyun.com/kubernetes/apt kubernetes-xenia 

l/main amd64 kubectl amd64 1.10.1-00 [8,906 kB] 

Get:5 https://mirrors.aliyun.com/kubernetes/apt kubernetes-xenia 

l/main amd64 kubeadm amd64 1.10.1-00 [20.7 MB] 

Fetched 56.9 MB in 5s (11.0 MB/s) 

Use of uninitialized value $ in lc at /usr/share/per15/Debconf/ 

Template.pm line 287. 

Selecting previously unselected package kubernetes-cni. 

(Reading database ... 191799 files and directories currently ins 

talled.) 

Preparing to unpack .../kubernetes-cni 0.6.0-00 amd64.deb 

Unpacking kubernetes-cni (0.6.0-00) 

Selecting previously unselected package socat. 

Preparing to unpack .../socat 1.7.3.1-1 amd64.deb 

Unpacking 


kubeadm 安 装 完 以 后 ， 就 可 以 使 用 它 来 快速 安装 部 署 Kubernetes 集 群 了 。 


1& F|kubeadm-x X Kubernetes % #% 


i$ A kubeadmin 34 UL master ? 点 


因为 使 用 要 使 用 canal， 因 此 需要 在 初始 化 时 加 上 网 络 配置 参数 ,设置 kubernetes 的 
子 网 为 10.244.0.0/16， 注 意 此 处 不 要 修改 为 其 他 地 址 ， 因 为 这 个 值 与 后 续 的 canal 
的 yaml 值 要 一 致 ， 如 果 修 改 ， 请 一 并 修改 。 


这 个 下 载 镜像 的 过 程 涉及 翻 墙 ， 因 为 会 从 gcr 的 站 点 下 载 容 器 镜像 。。。 (如 果 大 家 
翻 墙 不 方便 的 话 ， 可 以 用 我 在 上 文 准备 工作 中 提 到 的 导出 的 镜像 ) 。 


如 果 有 能 够 连接 gcr 站 点 的 网 络 ， 那 么 整个 安装 过 程 非常 简单 。 


# kubeadm init --pod-network-cidr=10.244.0.0/16 --apiserver-adve 
rtise-address=192.168.0.200 

[init] Using Kubernetes version: vi.10.1 

[init] Using Authorization modes: [Node RBAC] 

[preflight] Running pre-flight checks. 

[WARNING FileExisting-crictl]: crictl not found in system pa 

th 
Suggestion: go get github.com/kubernetes-incubator/cri-tools/cmd 
/crictl 

[preflight] Starting the kubelet service 

[certificates] Generated ca certificate and key. 

[certificates] Generated apiserver certificate and key. 
[certificates] apiserver serving cert is signed for DNS names [u 
buntu-master kubernetes kubernetes.default kubernetes.default.sv 
c kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 192.1 
68.0.200] 

[certificates] Generated apiserver-kubelet-client certificate an 
d key. 

[certificates] Generated etcd/ca certificate and key. 
[certificates] Generated etcd/server certificate and key. 
[certificates] etcd/server serving cert is signed for DNS names [ 
localhost] and IPs [127.0.0.1] 

[certificates] Generated etcd/peer certificate and key. 
[certificates] etcd/peer serving cert is signed for DNS names [u 
buntu-master] and IPs [192.168.0.200] 

[certificates] Generated etcd/healthcheck-client certificate and 
key. 

[certificates] Generated apiserver-etcd-client certificate and k 
ey. 

[certificates] Generated sa key and public key. 

[certificates] Generated front-proxy-ca certificate and key. 
[certificates] Generated front-proxy-client certificate and key. 
[certificates] Valid certificates and keys now exist in "/etc/ku 
bernetes/pki" 

[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/adm 
in.conf" 

[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/kub 
elet.conf" 

[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/con 
troller -manager.conf" 

[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/sch 


eduler.conf" 

[controlplane] Wrote Static Pod manifest for component kube-apis 
erver to "/etc/kubernetes/manifests/kube-apiserver.yam1l" 
[controlplane] Wrote Static Pod manifest for component kube-cont 
roller-manager to "/etc/kubernetes/manifests/kube-controller-man 
ager.yaml" 

[controlplane] Wrote Static Pod manifest for component kube-sche 
duler to "/etc/kubernetes/manifests/kube-scheduler. yam1" 

[etcd] Wrote Static Pod manifest for a local etcd instance to "/ 
etc/kubernetes/manifests/etcd.yaml" 

[init] Waiting for the kubelet to boot up the control plane as S 
tatic Pods from directory "/etc/kubernetes/manifests". 

[init] This might take a minute or longer if the control plane i 
mages have to be pulled. 

[apiclient] All control plane components are healthy after 28.00 
3828 seconds 

[uploadconfig] Storing the configuration used in ConfigMap "kube 
adm-config" in the "kube-system" Namespace 

[markmaster] Will mark node ubuntu-master as master by adding a 
label and a taint 

[markmaster] Master ubuntu-master tainted and labelled with key/ 
value: node-role.kubernetes.io/master="" 

[bootstraptoken] Using token: rw4enn.mvk547juq7qi2b5f 
[bootstraptoken] Configured RBAC rules to allow Node Bootstrap t 
okens to post CSRs in order for nodes to get long term certifica 
te credentials 

[bootstraptoken] Configured RBAC rules to allow the csrapprover 
controller automatically approve CSRs from a Node Bootstrap Toke 
n 

[bootstraptoken] Configured RBAC rules to allow certificate rota 
tion for all node client certificates in the cluster 
[bootstraptoken] Creating the "cluster-info" ConfigMap in the "k 
ube-public" namespace 

[addons] Applied essential addon: kube-dns 

[addons] Applied essential addon: kube-proxy 


Your Kubernetes master has initialized successfully! 


To start using your cluster, you need to run the following as a 
regular user: 


mkdir -p $HOME/.kube 
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config 
sudo chown $(id -u):$(id -g) $HOME/.kube/config 


You should now deploy a pod network to the cluster. 

Run "kubectl apply -f [podnetwork].yaml" with one of the options 
listed at: 
https://kubernetes.io/docs/concepts/cluster-administration/add 

ons/ 


You can now join any number of machines by running the following 
on each node 


as root: 


kubeadm join 192.168.0.200:6443 --token rw4enn.mvk547juq7qi2b5 
f --discovery-token-ca-cert-hash sha256:ba260d5191213382a806a9a7 
d92c9e6bb09061847c7914b1ac584d0c69471579 


El = zn 





执行 如 下 命令 来 配置 Kubectl » 


mkdir -p $HOME/.kube 
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config 
sudo chown $(id -u):$(id -g) $HOME/.kube/config 


这 样 master 的 节点 就 配置 好 了 ， 并 且 可 以 使 用 kubectl 来 进行 各 种 操作 了 ， 根 据 上 面 
的 提示 接着 往 下 做 ， 将 slave 节 点 加 入 到 集群 。 


Slave 节 点 加 入 集群 
在 Slave 节 点 执行 如 下 的 命令 ,将 slave 节 点 加 入 集群 ， 正 常 的 返回 信息 如 下 : 


#kubeadm join 192.168.0.200:6443 --token rw4enn.mvk547juq7qi2b5f 

--discovery-token-ca-cert-hash sha256:ba260d5191213382a806a9a7d 
92c9e6bb09061847c7914b1ac584d0c69471579 

[preflight] Running pre-flight checks. 

[WARNING FileExisting-crictl]: crictl not found in system pa 

th 
Suggestion: go get github.com/kubernetes-incubator/cri-tools/cmd 
/crictl 

[discovery] Trying to connect to API Server "192.168.0.200:6443" 
[discovery] Created cluster-info discovery client, requesting in 
fo from "https://192.168.0.200:6443" 

[discovery] Requesting info from "https://192.168.0.200:6443" ag 
ain to validate TLS against the pinned public key 

[discovery] Cluster info signature and contents are valid and TL 
S certificate validates against pinned roots, will use API Serve 
r "192.168.0.200:6443" 

[discovery] Successfully established connection with API Server 
"192,168 .6,200: 9443" 


This node has joined the cluster: 

* Certificate signing request was sent to master and a response 
was received. 

* The Kubelet was informed of the new secure connection details. 


Run 'kubectl get nodes' on the master to see this node join the 
cluster. 


等 待 节点 加 入 完毕 。 加 入 中 状态 。 


# kubectl get node 


NAME STATUS ROLES AGE VERSION 
ubuntu-1 NotReady <none> 6m v1.10.1 
ubuntu-2 NotReady <none> 6m v1.10.1 
ubuntu-3 NotReady «none» 6m v1.10.1 
ubuntu-master NotReady master 10m v1.10.1 


在 master 节 点 查看 信息 如 下 状态 为 节点 加 入 完毕 。 


root@Ubuntu-master:~# kubectl get pod -n kube-system -0 wide 


NAME READY STATUS REST 

ARTS AGE IP NODE 

etcd-ubuntu-master 1/1 Running 0 
21m 192.168.0.200 ubuntu-master 

kube-apiserver-ubuntu-master 1/1 Running 0 
21m 192.168.0.200 ubuntu-master 

kube-controller -manager -ubuntu-master 1/1 Running 0 
22m 192.168.0.200 ubuntu-master 

kube-dns -86f4d74b45-wkfk2 0/3 Pending 0 
22m <none> <none> 

kube-proxy-6ddb4 1/1 Running 0 
22m 192.168.0.200 ubuntu-master 

kube-proxy-7ngb9 1/1 Running 0 
17m 192.168.0.202 ubuntu-2 

kube-proxy-fkhhx 1/1 Running 0 
18m 192.168.0.201 ubuntu-1 

kube-proxy-rh4lq 1/1 Running 0 
18m 192.168.0.203 ubuntu-3 

kube- scheduler -ubuntu-master 1/1 Running 0 
21m 192.168.0.200 ubuntu-master 


kubedns 组 件 需 要 在 网 络 插件 完成 安装 以 后 会 自动 安装 完成 。 


安装 网 络 插件 canal 


从 canal 官 方 文档 参考 ， 如 下 网 址 下 载 2 个 文件 并 且 安 装 ， 其 中 一 个 是 配置 canal 的 
RBAC 权 限 ， 一 个 是 部 署 canal 的 DaemonSet ° 


# kubectl apply -f https://docs.projectcalico.org/v3.0/getting- 
started/kubernetes/installation/hosted/canal/rbac.yaml 
clusterrole.rbac.authorization.k8s.io "calico" created 
clusterrole.rbac.authorization.k8s.io "flannel" created 
clusterrolebinding.rbac.authorization.k8s.io "canal-flannel" cre 
ated 

clusterrolebinding.rbac.authorization.k8s.io "canal-calico" crea 
ted 


# kubectl apply -f https://docs.projectcalico.org/v3.0/getting-s 
tarted/kubernetes/installation/hosted/canal/canal.yaml 

configmap "canal-config" created 

daemonset.extensions "canal" created 
customresourcedefinition.apiextensions.k8s.io "felixconfiguratio 
ns.crd.projectcalico.org" created 
customresourcedefinition.apiextensions.k8s.io "bgpconfigurations 
.crd.projectcalico.org" created 
customresourcedefinition.apiextensions.k8s.io "ippools.crd.proje 
ctcalico.org" created 
customresourcedefinition.apiextensions.k8s.io "clusterinformatio 
ns.crd.projectcalico.org" created 
customresourcedefinition.apiextensions.k8s.io "globalnetworkpoli 
cies.crd.projectcalico.org" created 
customresourcedefinition.apiextensions.k8s.io "networkpolicies.c 
rd.projectcalico.org" created 

serviceaccount "canal" created 


查看 canal 的 安装 状态 。 


# kubectl get pod -n kube-system -o wide 


NAME READY STATUS REST 

ARTS AGE IP NODE 

canal-fc94k 3/3 Running 10 
4m 192.168.0.201 ubuntu-1 

canal-rs2wp 3/3 Running 10 
4m 192.168.0.200 ubuntu-master 

canal-tqd41 3/3 Running 10 
4m 192.168.0.202 ubuntu-2 

canal-vmpnr 3/3 Running 10 
4m 192.168.0.203 ubuntu-3 

etcd-ubuntu-master 1/1 Running 0 
28m 192.168.0.200 ubuntu-master 

kube-apiserver-ubuntu-master 1/1 Running 0 
28m 192.168.0.200 ubuntu-master 

kube-controller -manager -ubuntu-master 1/1 Running 0 
29m 192.168.0.200 ubuntu-master 

kube-dns -86f4d74b45-wkfk2 3/3 Running 0 
28m 10.244.2.2 ubuntu-3 

kube-proxy-6ddb4 1/1 Running 0 
28m 192.168.0.200 ubuntu-master 

kube-proxy-7ngb9 1/1 Running 0 
24m 192.168.0.202 ubuntu-2 

kube-proxy-fkhhx 1/1 Running 0 
24m 192.168.0.201 ubuntu-1 

kube-proxy-rh4lq 1/1 Running 0 
24m 192.168.0.203 ubuntu-3 

kube- scheduler -ubuntu-master 1/1 Running 0 
28m 192.168.0.200 ubuntu-master 


可 以 看 到 canal 和 kube-dns 都 已 经 运行 正常 ， 一 个 基本 功能 正常 的 测试 环境 就 部 署 


ET 


此 时 查看 集群 的 节点 状态 ， 版 本 为 最 新 的 版 本 v1.10.1。 


# kubectl get node 


NAME STATUS ROLES AGE VERSION 
ubuntu-1 Ready «none» 27m v1.10.1 
ubuntu-2 Ready «none» 27m v1.10.1 
ubuntu-3 Ready «none» 27m v1.10.1 
ubuntu-master Ready master 31m v1.10.1 


让 master 也 运行 pod (默认 master 不 运行 pod ) ,这 样 在 测试 环境 做 是 可 以 的 ， 不 建 
议 在 生产 环境 如 此 操作 。 


#kubectl taint nodes --all node-role.kubernetes.io/master - 
node "ubuntu-master" untainted 

taint "node-role.kubernetes.io/master:" not found 

taint "node-role.kubernetes.io/master:" not found 

taint "node-role.kubernetes.io/master:" not found 


后 续 如 果 想 要 集群 其 他 功能 启用 ， 请 参考 后 续 文章 。 
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服务 发 现 与 负载 均衡 


Kubernetes 在 设计 之 初 就 充分 考虑 了 针对 容器 的 服务 发 现 与 负载 均衡 机 制 ， 提 供 了 
Service 资 源 ， 并 通过 kube-proxy 配 合 cloud provider 来 适应 不 同 的 应 用 场景 。 随 着 

kubernetes 用 户 的 激增 ， 用 户 场景 的 不 断 丰 富 ， 又 产生 了 一 些 新 的 负载 均衡 机 制 。 
目前 ，kubernetes 中 的 负载 均衡 大 致 可 以 分 为 以 下 几 种 机 制 ， 每 种 机 制 都 有 其 特定 
的 应 用 场景 : 


e Service : 直接 用 Service 提 供 cluster 内 部 的 负载 均衡 ， 并 借助 cloud provider 提 
供 的 LB 提供 外 部 访问 

e Ingress Controller : 还 是 用 Service 提 供 cluster 内 部 的 负载 均衡 ， 但 是 通过 自 定 
义 LB 提 供 外 部 访问 

e Service Load Balancer : 把 load balancer 直 接 跑 在 容器 中 ， 实 现 Bare Metal 的 
Service Load Balancer 

e Custom Load Balancer : 自 定义 负载 均衡 ， 并 替代 kube-proxy， 一 般 在 物理 部 
署 Kubernetes 时 使 有 用， 方便 接 入 公司 已 有 的 外 部 服务 


Service 


Service 是 对 一 组 提供 相同 功能 的 Pods 的 抽象 ， 并 为 它们 提供 一 个 统一 的 入 口 。 借 
助 Service， 应 用 可 以 方便 的 实现 服务 发 现 与 负载 均衡 ， 并 实现 应 用 的 零 宕 机 升级 。 
Service 通 过 标签 来 选取 服务 后 端 ， 一 般配 合 Replication Controller 或 者 Deployment 
来 保证 后 端 容器 的 正常 运行 。 


Service 有 三 种 类 型 : 


e ClusterlP : 默认 类 型 ， 自 动 分 配 一 个 仅 cluster 内 部 可 以 访问 的 虚拟 IP 

e NodePort : 在 ClusterIP 基 础 上 为 Service 在 每 台 机 器 上 绑 定 一 个 端口 ， 这 样 就 
可 以 通过 «NodeIP»:NodePort 来 访问 该 服务 

e LoadBalancer : 在 NodePort 的 基础 上 ， 人 借助 cloud provider 创 建 一 个 外 部 的 负 
载 均 衡器 ， 并 将 请 求 转 发 到 <NodeIP>:NodePort 


另外 ， 也 可 以 将 已 有 的 服务 以 Service 的 形式 加 入 到 Kubernetes 集 群 中 来 ， 只 需要 
在 创建 Service 的 时 候 不 指定 Label selector， 而 是 在 Service 创 建 好 后 手动 为 其 添加 
endpoint ° 


Ingress Controller 


Service 虽 然 解决 了 服务 发 现 和 负载 均衡 的 问题 ， 但 它 在 使 用 上 还 是 有 一 些 限 制 ， 比 
dm 


。 对 外 访问 的 时 候 ，NodePort 类 型 需要 在 外 部 搭建 额外 的 负载 均衡 ， 而 
LoadBalancer 要 求 kubernetes 必 须 跑 在 支持 的 cloud provider.E d 


Ingress 就 是 为 了 解决 这 些 限制 而 引入 的 新 资源 ， 主 要 用 来 将 服务 暴露 到 cluster 外 
面 ， 并 且 可 以 自 定义 服务 的 访问 策略 。 比 如 想 要 通过 负载 均衡 器 实现 不 同 子 域名 到 
不 同 服务 的 访问 : 


foo.bar.com --| |-» foo.bar.com s1:80 
| 178.91.123.132 | 
bar.foo.com --| |-> bar.foo.com s2:80 


可 以 这 样 来 定义 Ingress : 


apiVersion: extensions/vibetai 
kind: Ingress 
metadata: 

name: test 
spec: 

rules: 

- host: foo.bar.com 

http: 

paths: 

- backend: 
serviceName: si 
servicePort: 80 

- host: bar.foo.com 
http: 

paths: 

- backend: 
serviceName: s2 
servicePort: 80 


注意 : Ingress 本 身 并 不 会 自动 创建 负载 均衡 器 ，cluster 中 需要 运行 一 个 ingress 
controller 来 根据 Ingress 的 定义 来 管理 负载 均衡 器 。 目 前 社区 提供 了 nginx 和 gce 的 参 
考 实 现 。 


Traefik 提 供 了 易 用 的 Ingress Controller， 使 用 方法 见 https://docs .traefik.io/user- 
guide/kubernetes/。 


Service Load Balancer 


在 Ingress 出 现 以 前 ，Service Load Balancer & 4f 2$ 83 Af R Service 4 IRE 8 Zr X, o 
Service Load Balancer 将 haproxy 跑 在 容器 中 ， 并 监控 service 和 endpoint 的 变化 ， 
通过 容器 IP 对 外 提供 4 层 和 7 层 负载 均衡 服务 。 


社区 提供 的 Service Load Balancer 支 持 四 种 负载 均衡 协议 : TCP ^ HTTP ` HTTPS 
和 SSL TERMINATION， 并 支持 ACL 访 问 控制 。 


Custom Load Balancer 
虽然 Kubernetes 提 供 了 丰富 的 负载 均衡 机 制 ， 但 在 实际 使 用 的 时 候 ， 还 是 会 碰 到 一 
些 复 杂 的 场景 是 它 不 能 支持 的 ， 比 如 : 


e 接 入 已 有 的 负载 均衡 设备 
e 多 租户 网 络 情况 下 ， 容 器 网 络 和 主机 网 络 是 隔离 的 ， 这 样 kube-proxy 就 不 
能 正常 工作 


这 个 时 候 就 可 以 自 定义 组 件 ， 并 代替 kube-proxy 来 做 负载 均衡 。 基 本 的 思路 是 监控 
kubernetes 中 service 和 endpoints 的 变化 ， 并 根据 这 些 变化 来 配置 负载 均衡 器 。 比 
如 weave flux ` nginx plus、kube2haproxy 等 。 


Endpoints 


有 几 种 情况 下 需要 用 到 没有 selector 的 service。 


e 使 用 kubernetes 集 群 外 部 的 数据 库 时 
e Service 中 用 到 了 其 他 namespace 或 kubernetes 集 群 中 的 service 
e 在 kubernetes 的 工作 负载 与 集群 外 的 后 端 之 问 互 相 迁 移 


可 以 这 样 定义 一 个 没有 selector 的 service ° 


kind: Service 
apiVersion: vi 


metadata: 
name: my-service 
spec: 
ports: 
- protocol: TCP 
port: 80 


targetPort: 9376 


定义 一 个 Endpoints 来 对 应 该 service 。 


Kind: Endpoints 
apiVersion: v1 
metadata: 
name: my-service 
subsets: 
- addresses: 
- ip: 1.2.3.4 
ports: 
- port: 9376 


访问 没有 selector 的 service 跟 访问 有 selector 的 service 时 没有 任何 区 别 。 


使 用 kubernetes 时 有 一 个 很 常见 的 需求 ， 就 是 当 数 据 库 部 署 在 kubernetes 和 集群 之 外 
的 时 候 ， 集 群 内 的 service 如 何 访 问 数据 库 呢 ?当然 你 可 以 直接 使 用 数据 库 的 IP 地 址 
和 端口 号 来 直接 访问 ， 有 没有 什么 优雅 的 方式 呢 ? 你 需要 用 到 ExternalName 


Service ° 


kind: Service 
apiVersion: v1 
metadata: 
name: my-service 
namespace: prod 
spec: 
type: ExternalName 
externalName: my.database.example.com 
ports: 
- port: 12345 


这 个 例子 中 ， 在 kubernetes 集 群 内 访问 my-service 实际 上 会 重 定向 
到 my.database.example.com:12345 这 个 地 址 。 


服务 发 现 与 负载 均衡 


e https://kubernetes.io/docs/concepts/services-networking/service/ 

e http://kubernetes.io/docs/user-guide/ingress/ 

e https://github.com/kubernetes/contrib/tree/master/service-loadbalancer 

e https://www.nginx.com/blog/load-balancing-kubernetes-services-nginx-plus/ 
e https://github.com/weaveworks/flux 

e https://github.com/AdoHe/kube2haproxy 
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安装 traefik ingress 


Ingress 简 介 


如 果 你 还 不 了 解 ，ingress 是 什么 ， 可 以 先 看 下 我 翻译 的 Kubernetes 官 网 上 ingress 
的 介绍 Kubernetes Ingress 解 析 。 


理解 Ingress 


简单 的 说 ，ingress 就 是 从 kubernetes 和 集群 外 访问 集群 的 入 口 ， 将 用 户 的 URL 请 求 转 
发 到 不 同 的 service 上 。|ngress 相 当 于 nginx、apache 等 负载 均衡 方向 代理 服务 器 ， 
其 中 还 包括 规则 定义 ， 即 URL 的 路 由 信息 ， 路 由 信息 得 的 刷新 由 Ingress controller 
来 提供 。 


理解 Ingress Controller 


Ingress Controller 实质 上 可 以 理解 为 是 个 监视 器 ，lngress Controller 通过 不 断 地 跟 
kubernetes API 打交道 ， 实 时 的 感知 后 端 service ^ pod 等 变化 ， 比 如 新 增 和 减少 
pod > service 增加 与 减少 等 ; 当 得 到 这 些 变化 信息 后 ，lIngress Controller 再 结合 下 
文 的 Ingress 生成 配置 ， 然 后 更 新 反 向 代理 负载 均衡 器 ， 并 刷新 其 配置 ， 达 到 服务 
发 现 的 作用 。 


部 署 Traefik 


介绍 traefik 


Traefik 是 一 款 开 源 的 反 向 代理 与 负载 均衡 工具 。 它 最 大 的 优点 是 能 够 与 常见 的 微服 
务 系统 直接 整合 ， 可 以 实现 自动 化 动态 配置 。 目 前 支持 Docker Swarm, 
Mesos/Marathon, Mesos, Kubernetes, Consul, Etcd, Zookeeper, BoltDB, Rest API 
等 等 后 端 模型 。 


以 下 配置 文件 可 以 在 kubernetes-handbookGitHub 仓 库 中 的 ..Jmanifests/traefik- 
ingress/ 目 录 下 找到 。 


创建 ingress-rbac.yaml 


将 用 于 service account 验 证 。 


apiVersion: v1 
kind: ServiceAccount 
metadata: 
name: ingress 
namespace: kube-system 


kind: ClusterRoleBinding 
apiVersion: rbac.authorization.k8s.io/vibeta1 
metadata: 
name: ingress 
subjects: 
- kind: ServiceAccount 
name: ingress 
namespace: kube-system 
roleRef: 
kind: ClusterRole 
name: cluster-admin 
apiGroup: rbac.authorization.k8s.io 


创建 名 为 traefik-ingress “ingress > x 4t Z ingress.yaml 


apiVersion: extensions/vibeta1 
kind: Ingress 
metadata: 
name: traefik-ingress 
namespace: default 
spec: 
rules: 
- host: traefik.nginx.io 
http: 
paths: 
- path: / 
backend: 
serviceName: my-nginx 
servicePort: 80 
- host: traefik.frontend.io 


nttp: 
paths: 
- path: / 
backend: 


serviceName: frontend 
servicePort: 80 


这 其 中 的 backend 中 要 配置 default namespace ? È z/ service.Z F > w RRA 
A it namespace. 2 F > RU M default namespace， 如 果 你 在 其 他 namespace 
中 创建 服务 想 要 暴露 到 kubernetes 集 群 外 部 ， 可 以 创建 新 的 ingress.yaml 文 件 ， 同 


时 在 文件 中 指定 该 namespace ， 其 他 配置 与 上 面 的 文件 格式 相同 。。 path 就 是 
URL 地 址 后 的 路 径 ， 如 traefik.frontend.io/path ，service 将 会 接受 path 这 个 路 径 ， 
host 最 好 使 用 service-name.filed1.filed2.domain-name 这 种 类 似 主 机 名 称 的 命名 方 
式 ， 方 便 区 分 服务 。 


根据 你 自己 环境 中 部 署 的 service 的 名 字 和 端口 自行 修改 ， 有 新 service 增加 时 ， 修 改 
该 文件 后 可 以 使 用 kubectl replace -f ingress.yaml 来 更 新 。 


我 们 现在 集群 中 已 经 有 两 个 service 了 ， 一 个 是 nginx， 另 一 个 是 官方 
的 guestbook 例子 。 


创建 DaemonSet 


我 们 使 用 DaemonSet 类 型 来 部 署 Traefik ， 并 使 用 nodeSelector 来 限定 Traefik 所 
部 署 的 主机 。 


apiVersion: extensions/vibeta1 
kind: DaemonSet 
metadata: 
name: traefik-ingress-lb 
namespace: kube-system 
labels: 
k8s-app: traefik-ingress-lb 
spec: 
template: 
metadata: 
labels: 
k8s-app: traefik-ingress-lb 
name: traefik-ingress-lb 
spec: 
terminationGracePeriodSeconds: 60 
hostNetwork: true 
restartPolicy: Always 
serviceAccountName: ingress 
containers: 
- image: traefik 
name: traefik-ingress-lb 
resources: 
limits: 
cpu: 200m 
memory: 30Mi 
requests: 
cpu: 100m 
memory: 20Mi 
ports: 
- name: http 
containerPort: 80 
hostPort: 80 
- name: admin 
containerPort: 8580 
hostPort: 8580 


- --web.address=: 8580 

- --kubernetes 
nodeSelector: 

edgenode: "true" 


注意 : 我 们 使 用 了 nodeselector 选择 边缘 节点 来 调度 traefik-ingress-lb 运 行 在 它 
上 面 ， 所 有 你 需要 使 用 : 


kubectl label nodes 172.20.0.113 edgenode=true 
kubectl label nodes 172.20.0.114 edgenode=true 
kubectl label nodes 172.20.0.115 edgenode=true 


给 三 个 node 打 标签 ， 这 样 traefik 的 pod 才 会 调度 到 这 几 台 主机 上 ， 否 则 会 一 直 
于 pending 状态 。 


关于 使 用 Traefik 作 为 边缘 节点 请 参考 边缘 节点 配置 。 
Traefik UI 


使 用 下 面 的 yaml 配 置 来 创建 Traefik 的 Web UI ° 


apiVersion: vi 
kind: Service 
metadata: 
name: traefik-web-ui 
namespace: kube-system 
spec: 
selector: 
k8s-app: traefik-ingress-lb 
ports: 
- name: web 
port: 80 
targetPort: 8580 
apiVersion: extensions/vibeta1 
kind: Ingress 
metadata: 
name: traefik-web-ui 
namespace: kube-system 
spec: 
rules: 
- host: traefik-ui.local 
http: 
paths: 
- path: / 
backend: 
serviceName: traefik-web-ui 
servicePort: web 


配置 完成 后 就 可 以 启动 treafik ingress T. ° 
kubectl create -f 


我 查看 到 traefik 的 pod 在 172.20.0.115 这 人 台 节 点 上 启动 了 。 


访问 该 地 址 http://172.20.0.115:8580/ 将 可 以 看 到 dashboard 。 


= 


e Providers Health 


kubernetes 


Q traefik-ui.local/ 


Route Rule 
/ PathPrefix:/ 


traefik-ui.local Host:traefik-ui.local 


ICIO Ge CI 


Q traefik.frontend.io/ 


Route Rule 
/ PathPrefix:/ 


traefik.frontend.io Host: traefik. frontend. io 


CI CO CD 


Q traefik.nginx.io/ 


Route Rule 
/ PathPrefix:/ 


traefik.nginx.io Host: traefik.nginx. io 


[ET E 


图 片 - kubernetes-dashboard 


= traefik-ui.local/ 


Server 
traefik-ingress-Ib- 


4237248072-4009r 


Load Balancer: wrr 


= traefik.frontend.io/ 


Server 


frontend-1289468719- 
6l4v7 


frontend-1289468719- 
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frontend-1289468719- 
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Load Balancer: wrr 


= traefik.nginx.io/ 


Server 


my-nginx-2096504489- 
lig9c 


my-nginx-2096504489- 
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v1.2.3 / morbier Documentation traefik.io 


URL Weight 


http://172.20.0.115 1 
78580 


URL Weight 


http://172.30.60.11 1 
:80 


http://172.30.71.5: 1 
80 


http://172.30.94.9: 1 
80 


URL Weight 


http://172.30.60.5: 1 
80 


http://172.30.94.6: 1 
80 


左 侧 黄 色 部 分 部 分 列 出 的 是 所 有 的 rule， 右 侧 绿 色 部 分 是 所 有 的 backend ° 


测 试 


在 集群 的 任意 一 个 节点 上 执行 。 假 如 现在 我 要 访问 nginX 的 "/" 路 径 。 


$ curl -H Host: traefik.nginx.io http://172.20.0.115/ 
<!DOCTYPE html» 


<html> 
<head> 
<title>welcome to nginx!</title> 
<style> 
body { 
width: 35em; 
margin: © auto; 
font-family: Tahoma, Verdana, Arial, sans-serif; 
} 
</style> 
</head> 
<body> 


<hi>welcome to nginx!</h1> 

<p>If you see this page, the nginx web server is successfully in 
stalled and 

working. Further configuration is required.</p> 


<p>For online documentation and support please refer to 
«a href="http://nginx.org/">nginx.org</a>.<br/> 
Commercial support is available at 

<a href="http://nginx.com/">nginx.com</a>.</p> 


<p><em>Thank you for using nginx.</em></p> 


</body> 
</html> 


如 果 你 需要 在 kubernetes 集 群 以 外 访问 就 需要 设置 DNS， 或 者 修改 本 机 的 hosts 文 
件 。 


在 其 中 加 入 : 


172.20.0.115 traefik.nginx.io 
172.20.0.115 traefik.frontend.io 


所 有 访问 这 些 地 址 的 流量 都 会 发 送 给 172.20.0.115 这 台 主 机 ， 就 是 我 们 启动 traefik 
的 主机 。 


Traefik 会 解析 http 请 求 header 里 的 Host 参 数 将 流量 转发 给 Ingress 配 置 里 的 相应 
service ° 


修改 hosts 后 就 就 可 以 在 kubernetes 集 群 外 访问 以 上 两 个 service， 如 下 图 : 


Chrome File Edit View History Bookmarks People Window Help 





[3 Welcome to nginx! 


I C ñ © traefik.nginx.io 


Welcome to nginx! 


If you see this page, the nginx web server is successfully installed and 
working. Further configuration is required. 


For online documentation and support please refer to nginx.org. 
Commercial support is available at nginx.com. 


Thank you for using nginx. 
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安装 Traefik ingress 


730 


分 布 式 负载 测试 


该 教程 描述 如 何在 Kubernetes 中 进行 分 布 式 负载 均衡 测试 ， 包 括 一 个 web 应 用 、 
docker 镜 像 和 Kubernetes controllers/services。 关于 分 布 式 负 载 测 试 的 更 多 资料 请 
查看 Distributed Load Testing Using Kubernetes 。 


准备 
不 需要 GCE 及 其 他 组 件 ， 你 只 需要 有 一 个 kubernetes 集 群 即 可 。 


如 果 你 还 没有 kubernetes 集 群 ， 可 以 参考 kubernetes-handbook 部 署 一 个 。 


部 署 Web 应 用 


本 文中 使 用 的 镜像 、kubernetes 应 用 的 yaml 配 置 来 自我 的 另 一 个 项 目 ， 请 参 
考 : https://github.com/rootsongjc/distributed-load-testing-using-kubernetes 


sample-webapp 目录 下 包含 一 个 简单 的 web 测 试 应 用 。 我 们 将 其 构建 为 docker 镜 
像 ， 在 kubernetes 中 运行 。 你 可 以 自己 构建 ， 也 可 以 直接 用 这 个 我 构建 好 的 镜 
像 index.tenxcloud.com/jimmy/k8s-sample-webapp:latest ° 


在 kubernetes 上 部 署 sample-webapp。 


$ git clone https://github.com/rootsongjc/distributed-load-testi 
ng-using-kubernetes.git 

$ cd kubernetes-config 

$ kubectl create -f sample-webapp-controller.yaml 

$ kubectl create -f sample-webapp-service.yaml 


3 # Locust) Controller- Service 


locust-master 和 locust-work 使 用 同样 的 docker 镜 像 ， 修 改 cotnroller 
中 spec.template.spec.containers.env 字段 中 的 value 为 你 sample-webapp 
service 的 名 字 。 


- name: TARGET_HOST 
value: http://sample-webapp: 8000 


4] 32 Controller Docker#2 1% (可 选 ) 
locust-master 和 locust-work controller 使 用 的 都 是 locust-tasks docker 
镜像 。 你 可 以 直接 下 载 gcr.io/cloud-solutions-images/locust-tasks ， 也 


可 以 自己 编译 。 自 己 编译 大 概要 花 几 分 钟 时 间 ， 镜 像 大 小 为 820M © 


$ docker build -t index.tenxcloud.com/jimmy/locust-tasks:latest 


$ docker push index.tenxcloud.com/jimmy/locust-tasks:latest 


注意 : 我 使 用 的 是 时 速 云 的 镜像 仓库 。 


每 个 controller 的 yaml 的 spec.template.spec.containers.image 字段 指定 的 是 


我 的 镜像 : 


image: index.tenxcloud.com/jimmy/locust-tasks:latest 


#8 2 locust-master 


$ kubectl create -f locust-master-controller.yaml 
$ kubectl create -f locust-master-service.yaml 


#8 2 locust-worker 


Now deploy locust-worker-controller : 
$ kubectl create -f locust-worker-controller.yaml 
你 可 以 很 轻易 的 给 work 扩 容 ， 通 过 命令 行 方式 : 


$ kubectl scale --replicas-20 replicationcontrollers locust-work 
er 


分 布 式 负载 测试 


当然 你 也 可 以 通过 WebUl : Dashboard - Workloads - Replication Controllers - 
ServiceName - Scale 来 扩容 。 


Set desired number of pods 


Replication controller will be updated to reflect the desired count. 


Number of pods* 


CANCEL OK 





图 片 -使 用 qashboard 来 扩容 


配置 Traefik 


参考 kubernetes 的 traefik ingress 安 装 ， 在 ingress.yaml 中 加 入 如 下 配置 : 


- host: traefik.locust.io 


http: 
paths: 
- path: / 
backend: 


serviceName: locust-master 
servicePort: 8089 


然后 执行 kubectl replace -f ingress.yaml 即 可 更 新 traefik。 


通过 Traefik 的 dashboard 就 可 以 看 到 刚 增 加 的 traefik.locust.io 节点 。 


733 








Server URL Weignt 
Route Rule 
frontend-1289468719- http://172.30.94.9: 1 
/ PathPrefix:/ 4565s 80 
traefik.guestbook.io Host: traefik.guestbook. io frontend-1289468719- http://172.30.71.3: 1 
rf8rw 80 
orne | PassHostHeader | Priority:1 | frontend-1289468719- ^ http://172.30.94.10 1 
s4m6p 780 
Q traefik.locust.io/ 
Load Balancer: wrr 
Route Rule 
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/ PathPrefix:/ 
traefik.locust.io Host: traefik. locust. io Server URL Weight 
locust-master-p8vpn http://172.30.94.3: 1 
CE Ss | Priority: | Pen 
Q traefik.nginx.io/ Load Balancer: wrr 
pouto ule = traefik.nginx.io/ 
/ PathPrefix:/ 
Server URL Weight 


traefik.nginx.io Host: traefik.nginx. io 
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6l1zs 
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执行 测试 


打开 http://traefik.locust.io 页 


http://172.30.71.11 
:80 


http://172.30.71.10 
:80 


http://172.30.94.8: 
80 


http://172.30.71.12 
:80 


http://172.30.94.11 
:80 


秒 发送 的 请 求 个 数 ， 点 击 Start Swarming 就 可 以 开始 测试 了 。 


面 ， 点 击 Edit 输入 伪造 的 用 户 数 和 用 户 每 





O @ Sk STATUS SLAVES RPS FAILURES Reset Stats 
| | | RUNNING 1% 
0 
1141 users 30 43.9 
A MODERN LOAD TESTING TOOL Edit 





Statistics 


Nogin 
hanc 


/metrics yY 


Total Number of users to simulate 


Hatch rate 


Start swarming 
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在 测试 过 程 中 调整 sample-webapp 的 pod 个 数 (默认 设置 了 1 个 pod) > pod 
的 负载 变化 情况 。 





kubernetes Replication Controlle sample-webapp SCALE A^ EDIT DELETE + CREATE 
Time Time 
Admin 
Namespaces 
Nodes Details 
Persistent Volumes 
Name: sample-webapp Status 


Storage Classes . 
Namespace: default Pods: 3 running 


Labels: Y 
Namespace name: sample-webapp 


Creation time: 2017-04-24T12:31 
default 
Label selector: name: sample-webapp 


Workloads Images: sz-pg-oam-docker-hub-001.tendcloud.com/library/k8s-sample-webapp:latest 


Deployments 





Replica Sets . 
Services 
Replication Controllers 
Daemon Sets Name Labels uster IP Internal endpoints External endpoints 
le-webapp:8000 TCP E 
Stateful Sets sample-webai name: fleet 1 4,190.1 sampl : 
© ple-webapp ame: sample-webapp 0.25: 0.152 sample-webapp:0 TCP 3 
Jobs 
Pods 
Pods 
Services and discovery 
Name Status Restarts Age CPU (cores) Memory (bytes) 
Services _ 
@ :amplewebapp-546qg Running 0 36minutes — B 0.026 EE 22.555 wi mi 
Ingresses 
@ sample-webapp-9xg81 Running 0 36minutes BA 0 IRE 20.852 vi Ei 
Storage 
sample-webapp-s43t0 Runnin: 0 44 minutes 0.027 21.441 M = 3 
Persistent Volume Claims @ samp Be 3 B =a i 
Config 
Horizontal Pod Autoscalers 
Secrets 
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从 一 段 时 间 的 观察 中 可 以 看 到 负载 被 平均 分 配给 了 3 个 pod。 


在 locust 的 页 面 中 可 以 实时 观 


LOCUST 


AMODERN LOAD TESTING TOOL 


Statistics 


POST Nogin 664 


POST /metrics 660469 


Total 661133 


察 也 可 以 下 载 测试 结果 。 


ae id SLAVES RPS 
1180 users 30 16.5 
Edit 


图 片 - Locust 测 试 结果 页 面 
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Kubernetes 网 络 和 集群 性 能 测试 


准备 
测试 环境 
在 以 下 几 种 环境 下 进行 测试 : 


e Kubernetes 集 群 node 节 点 上 通过 Cluster IP 方 式 访问 
e Kubernetes 集 群 内 部 通 
e Kubernetes 集 群 外 部 通 


过 Service 人 访问 

过 traefik ingress # $& 04 3, 4E 7 | 
测试 地 址 

Cluster IP: 10.254.149.31 

Service Port : 8000 

Ingress Host : traefik.sample-webapp.io 


测试 工具 


e Locust: 一 个 简单 易 用 的 用 户 负载 测试 工具 ， 用 来 测试 Web 或 其 他 系统 能 够 同 
时 处 理 的 并 发 用 户 数 。 

e curl 

e kubemark 

e 测试 程序 : sample-webapp > 243 Github kubernetes 的 分 布 式 负载 测试 


测试 说 明 
通过 向 sample-webapp 发 送 curl 请 求 获取 响应 时 间 ， 直 接 curl 后 的 结果 为 : 


$ curl "http://10.254.149.31:8000/" 
Welcome to the "Distributed Load Testing Using Kubernetes" sampl 
e web app 


网 络 延迟 测试 


场景 一 、Kubernetes 集 群 node 节 点 上 通过 Cluster IP 
访问 


curl -0 /dev/null -s -w '%{time_connect} %{time_starttransfer} % 
{time_total}' "http://10.254.149.31:8000/" 


10 组 测试 结果 


No time_connect time_starttransfer time_total 
1 0.000 0.003 0.003 
2 0.000 0.002 0.002 
3 0.000 0.002 0.002 
4 0.000 0.002 0.002 
5 0.000 0.002 0.002 
6 0.000 0.002 0.002 
7 0.000 0.002 0.002 
8 0.000 0.002 0.002 
9 0.000 0.002 0.002 
10 0.000 0.002 0.002 


平均 响应 时 间 : 2ms 

时 间 指 标 说 明 

单位 : 秒 

time_connect : 建立 到 服务 器 的 TCP 连接 所 用 的 时 间 


time starttransfer : 在 发 出 请 求 之 后 ，Web 服务 器 返回 数据 的 第 一 个 字 节 所 用 的 时 
间 


time total : 完成 请 求 所 用 的 时 间 


4% — ` Kubernetes #4 A 28 38 it service% |] 


测试 命令 


curl -0 /dev/null -s -w '%{time_connect} %{time_starttransfer} % 
{time_total}' "http://sample-webapp:8000/" 


10 组 测试 结果 
No time_connect time_starttransfer time_total 
1 0.004 0.006 0.006 
2 0.004 0.006 0.006 
3 0.004 0.006 0.006 
4 0.004 0.006 0.006 
5 0.004 0.006 0.006 
6 0.004 0.006 0.006 
7 0.004 0.006 0.006 
8 0.004 0.006 0.006 
9 0.004 0.006 0.006 
10 0.004 0.006 0.006 


平均 响应 时 间 : 6ms 
场景 三 、 在 公 网 上 通过 traefik ingress 访 问 


curl -o /dev/null -s -w '%{time_connect} %{time_starttransfer} % 
{time_total}' "http://traefik.sample-webapp.io" >>result 


10 组 测试 结果 


No time_connect time_starttransfer time_total 


1 0.043 0.085 0.085 
2 0.052 0.093 0.093 
3 0.043 0.082 0.082 
4 0.051 0.093 0.093 
5 0.068 0.188 0.188 
6 0.049 0.089 0.089 
7 0.051 0.113 0.113 
8 0.055 0.120 0.120 
9 0.065 0.126 0.127 
10 0.050 0.111 0.111 


平均 响应 时 间 : 110ms 


测试 结果 


在 这 三 种 场景 下 的 响应 时 间 测 试 结果 如 下 


e Kubernetes 集 群 node 节 点 上 通过 Cluster IP 方 式 访问 : 2ms 
e Kubernetes 集 群 内 部 通过 service 访问 : 6ms 
e Kubernetes 集 群 外 部 通过 traefik ingress 暴 露 的 地 址 访问 : 110ms 


注意 : 执行 测试 的 node 节 点 /Pod 与 serivce 所 在 的 pod 的 距离 (是 否 在 同一 台 主 机 
上 ) ， 对 前 两 个 场景 可 以 能 会 有 一 定 影响 。 


网 络 性 能 测试 
网 络 使 用 flannel 的 vxlan 模 式 。 


使 用 iperf 进 行 测试 。 


iperf -s -p 12345 -i 1 -M 


iperf -c ${server-ip} -p 12345 -i 1 -t 10 -w 20K 


场景 一 、 主 机 之 间 


[ ID] Interval Transfer Bandwidth 

[ 3] 0.0- 1.0 sec 598 MBytes 5.02 Gbits/sec 
[ 3] 1.0- 2.0 sec 637 MBytes 5.35 Gbits/sec 
[ 3] 2.0- 3.0 sec 664 MBytes 5.57 Gbits/sec 
[ 3] 3.0- 4.0 sec 657 MBytes 5.51 Gbits/sec 
[ 3] 4.0- 5.0 sec 641 MBytes 5.38 Gbits/sec 
[ 3] 5.0- 6.0 sec 639 MBytes 5.36 Gbits/sec 
[ 3] 6.0- 7.0 sec 628 MBytes 5.26 Gbits/sec 
[ 3] 7.0- 8.0 sec 649 MBytes 5.44 Gbits/sec 
[ 3] 8.0- 9.0 sec 638 MBytes 5.35 Gbits/sec 
[ 3] 9.0-10.0 sec 652 MBytes 5.47 Gbits/sec 
[ 3] 0.0-10.0 sec 6.25 GBytes 5.37 Gbits/sec 


场景 二 、 不 同 主机 的 Pod 之 间 ( 使 用 flannel 的 vxlan 模 
X) 


[ ID] Interval Transfer Bandwidth 

[ 3] 0.0- 1.0 sec 372 MBytes 3.12 Gbits/sec 
[ 3] 1.0- 2.0 sec 345 MBytes 2.89 Gbits/sec 
[ 3] 2.0- 3.0 sec 361 MBytes 3.03 Gbits/sec 
[ 3] 3.0- 4.0 sec 397 MBytes 3.33 Gbits/sec 
[ 3] 4.0- 5.0 sec 405 MBytes 3.40 Gbits/sec 
[ 3] 5.0- 6.0 sec 410 MBytes 3.44 Gbits/sec 
[ 3] 6.0- 7.0 sec 404 MBytes 3.39 Gbits/sec 
[ 3] 7.0- 8.0 sec 408 MBytes 3.42 Gbits/sec 
[ 3] 8.0- 9.0 sec 451 MBytes 3.78 Gbits/sec 
[ 3] 9.0-10.0 sec 387 MBytes 3.25 Gbits/sec 
[ 3] 0.0-10.0 sec 3.85 GBytes 3.30 Gbits/sec 


场景 三 、Node 与 非 同 主机 的 Pod 之 间 (1% M flannel 4) 
vxlan/& X ) 


[ ID] Interval Transfer Bandwidth 

[ 3] 0.0- 1.0 sec 372 MBytes 3.12 Gbits/sec 
[ 3] 1.0- 2.0 sec 420 MBytes 3.53 Gbits/sec 
[ 3] 2.0- 3.0 sec 434 MBytes 3.64 Gbits/sec 
[ 3] 3.0- 4.0 sec 409 MBytes 3.43 Gbits/sec 
[ 3] 4.0- 5.0 sec 382 MBytes 3.21 Gbits/sec 
[ 3] 5.0- 6.0 sec 408 MBytes 3.42 Gbits/sec 
[ 3] 6.0- 7.0 sec 403 MBytes 3.38 Gbits/sec 
[ 3] 7.0- 8.0 sec 423 MBytes 3.55 Gbits/sec 
[ 3] 8.0- 9.0 sec 376 MBytes 3.15 Gbits/sec 
[ 3] 9.0-10.0 sec 451 MBytes 3.78 Gbits/sec 
[ 3] 0.0-10.0 sec 3.98 GBytes 3.42 Gbits/sec 


场景 四 、 不 同 主机 的 Pod 之 间 (使 用 flannel 的 host-gw 
模式 ) 


[ ID] Interval Transfer Bandwidth 

[ 5] 0.0- 1.0 sec 530 MBytes 4.45 Gbits/sec 
[ 5] 1.0- 2.0 sec 576 MBytes 4.84 Gbits/sec 
[ 5] 2.0- 3.0 sec 631 MBytes 5.29 Gbits/sec 
[ 5] 3.0- 4.0 sec 580 MBytes 4.87 Gbits/sec 
[ 5] 4.0- 5.0 sec 627 MBytes 5.26 Gbits/sec 
[ 5] 5.0- 6.0 sec 578 MBytes 4.85 Gbits/sec 
[ 5] 6.0- 7.0 sec 584 MBytes 4.90 Gbits/sec 
[ 5] 7.0- 8.0 sec 571 MBytes 4.79 Gbits/sec 
[ 5] 8.0- 9.0 sec 564 MBytes 4.73 Gbits/sec 
[ 5] 9.0-10.0 sec 572 MBytes 4.80 Gbits/sec 
[ 5] 0.0-10.0 sec 5.68 GBytes 4.88 Gbits/sec 


场景 五 、Node 与 非 同 主机 的 Pod 之 间 (1% M flannel 4 


ak ^ 
host-gwik x ) 

[ ID] Interval Transfer Bandwidth 

[ 3] 0.0- 1.0 sec 570 MBytes 4.78 Gbits/sec 
[ 3] 1.0- 2.0 sec 552 MBytes 4.63 Gbits/sec 
[ 3] 2.0- 3.0 sec 598 MBytes 5.02 Gbits/sec 
[ 3] 3.0- 4.0 sec 580 MBytes 4.87 Gbits/sec 
[ 3] 4.0- 5.0 sec 590 MBytes 4.95 Gbits/sec 
[ 3] 5.0- 6.0 sec 594 MBytes 4.98 Gbits/sec 
[ 3] 6.0- 7.0 sec 598 MBytes 5.02 Gbits/sec 
[ 3] 7.0- 8.0 sec 606 MBytes 5.08 Gbits/sec 
[ 3] 8.0- 9.0 sec 596 MBytes 5.00 Gbits/sec 
[ 3] 9.0-10.0 sec 604 MBytes 5.07 Gbits/sec 
[ 3] 0.0-10.0 sec 5.75 GBytes 4.94 Gbits/sec 


网 络 性 能 对 比 综述 


使 用 Flannel 的 vxlan 模 式 实现 每 个 pod 一 个 IP 的 方式 ， 会 比 宿主 机 直接 互联 的 网 络 
性 能 损耗 30%~40%， 符 合 网 上 流传 的 测试 结论 。 而 flannel 的 host-gw 模 式 比 起 宿 
主机 互 连 的 网 络 性 能 损耗 大 约 是 10% 。 


Vxlan 会 有 一 个 封包 解 包 的 过 程 ， 所 以 会 对 网 络 性 能 造成 较 大 的 损耗 ， 而 host-gw 模 
式 是 直接 使 用 路 由 信息 ， 网 络 损耗 小 ， 关 于 host-gw 的 架构 请 访问 Flannel host-gw 
architecture。 


Kubernete 的 性 能 测试 


参考 Kubernetes 集 群 性 能 测试 中 的 步骤 ， 对 kubernetes 的 性 能 进行 测试 。 


我 的 集群 版 本 是 Kubernetes1.6.0， 首 先 克 隆 代 码 ， 将 kubernetes 目 录 复 制 
到 $GOPATH/src/k8s.io/ 下 然后 执行 : 


$ ./hack/generate-bindata.sh 

/usr/local/src/k8s.io/kubernetes /usr/local/src/k8s.io/kubernete 
S 

Generated bindata file : test/e2e/generated/bindata.go has 13498 
test/e2e/generated/bindata.go lines of lovely automated artifac 
ts 

No changes in generated bindata file: pkg/generated/bindata.go 

/usr/local/src/k8s.io/kubernetes 

$ make WHAT="test/e2e/e2e.test" 


+++ [0425 17:01:34] Generating bindata: 
test/e2e/generated/gobindata util.go 

/usr/local/src/k8s.io/kubernetes /usr/local/src/k8s.io/kubernete 

s/test/e2e/generated 

/usr/local/src/k8s.io/kubernetes/test/e2e/generated 

+++ [0425 17:01:34] Building go targets for linux/amd64: 
test/e2e/e2e.test 

$ make ginkgo 

+++ [0425 17:05:57] Building the toolchain targets: 
k8s.io/kubernetes/hack/cmd/teststale 
k8s.io/kubernetes/vendor/github.com/jteeuwen/go-bindata/go-b 

indata 

+++ [0425 17:05:57] Generating bindata: 
test/e2e/generated/gobindata util.go 

/usr/local/src/k8s.io/kubernetes /usr/local/src/k8s.io/kubernete 

s/test/e2e/generated 

/usr/local/src/k8s.io/kubernetes/test/e2e/generated 

+++ [0425 17:05:58] Building go targets for linux/amde4: 
vendor/github.com/onsi/ginkgo/ginkgo 


$ export KUBERNETES PROVIDER-local 

$ export KUBECTL PATH-/usr/bin/kubectl 

$ go run hack/e2e.go -v -test --test_args="--host=http://172.20 
.0.113:8080 --ginkgo.focus-N[Feature:PerformanceN]" >>log.txt 


测试 结果 


Apr 25 18:27:31.461: INFO: API calls latencies: { 


"apicalis": [ 


{ 
"resource": "pods", 
"verb": "POST", 
"latency": ( 
"Perc50": 2148000, 
"Perc90": 13772000, 
"Perc99": 14436000, 
"Perc100": 0 
} 
um 
{ 
"resource": "services", 
"verb": "DELETE", 
"latency": { 
"Perc50": 9843000, 
"Perc90": 11226000, 
"Perc99": 12391000, 
"Perc100": 0 
} 
} 

Apr 25 18:27:31.461: INFO: [Result:Performance] { 
"version": "v1", 
"dataItems": [ 

{ 

"data": { 
"Perc50": 2.148, 
"Perc90": 13.772, 
"Perc99": 14.436 

}, 

"umit" * "ms", 

"labels": { 
"Resource": "pods", 


"Verb": "POST" 


j 
ty 


2.857: INFO: Running AfterSuite actions on all node 
Apr 26 10:35:32.857: INFO: Running AfterSuite actions on node 1 


Ran 2 of 606 Specs in 268.371 seconds 
SUCCESS! -- 2 Passed | 0 Failed | 0 Pending | 604 Skipped PASS 


Ginkgo ran 1 suite in 4m28.667870101s 


Test Suite Passed 


从 kubemark 输 出 的 日 志 中 可 以 看 到 APl calls latencies# Performance 。 


日 志 里 显示 ， 创 建 90 个 pod 用 时 40 秒 以 内 ， 平 均 创 建 每 个 pod 耗 时 0.44 秒 。 


不 同 type 的 资源 类 型 API 请 求 耗 时 分 布 


Resource Verb 50% 90% 99% 
services DELETE 8.472ms 9.841ms 38.226ms 
endpoints PUT 1.641ms 3.161ms 30.715ms 
endpoints GET 931yus 10.412ms 27.97ms 
nodes PATCH 4.245ms 11.117ms 18.63ms 
pods PUT 2.193ms 2.619ms 17.285ms 


从 log.txt 日 志 中 还 可 以 看 到 更 多 详细 请 求 的 测试 指标 。 





三 kubernetes Workloads > Replication Controllers 十 CREATE 
Admin 
Replication Controllers 1-100f13 K < > >I 
Namespaces 
Nodes Name Labels Pods Age Images 
Persistent Volumes eo load-medium-1 name: load-medium-1 30/30 44 seconds gcr.io/google. containers/serve hostname:v1.4 
Storage Classes eo load-small-1 name: load-small-1 5/5 43 seconds gcr.io/google. containers/serve hostname:v1.4 
Namespace eo load-small-10 name: load-small-10 5/5 42 seconds gcr.io/google. containers/serve hostname:v1.4 
e2e-tests-load-30-nodepods-1-: @ loadsmall11 name: load-small-11 5/5 36 seconds gcr.io/google. containers/serve hostname:v1.4 
Workloads eo load-small-12 name: load-small-12 5/5 36 seconds gcr.io/google. containers/serve hostname:v1.4 
Deployments eo load-small-2 name: load-small-2 5/5 36 seconds gcr.io/google. containers/serve hostname:v1.4 
Replica Sets 
eo load-small-3 name: load-small-3 5/5 38 seconds gcr.io/google. containers/serve hostname:v1.4 
Replication Controllers 
e load-small-4 name: load-small-4 5/5 39 seconds gcr.io/google. containers/serve hostname:v1.4 
Daemon Sets 
Stateful Sets @ ioadsmall5 name: load-small-5 5/5 41 seconds gcr.io/google. containers/serve hostname:v1.4 
Jobs eo load-small-6 name: load-small-6 5/5 38 seconds gcr.io/google. containers/serve hostname:v1.4 


Pods 
Services and discovery 


Services 


Ingresses 
Storage 

Persistent Volume Claims 
Config 


Secrets 


lA -kubernetes-dashboard 


注意 事项 


测试 过 程 中 需要 用 到 docker 镜 像 存 储 在 GCE 中 ， 需 要 翻 墙 下 载 ， 我 没 看 到 哪里 配置 
这 个 镜像 的 地 址 。 该 镜像 副本 已 上 传 时 速 云 : 


用 到 的 镜像 有 如 下 两 个 : 


e gcr.io/google_containers/pause-amd64:3.0 
e gcr.io/google_containers/serve_hostname:v1.4 


时 速 云 镜像 地 址 : 


e index.tenxcloud.com/jimmy/pause-amd64:3.0 
e index.tenxcloud.com/jimmy/serve_hostname:v1.4 


将 镜像 pull 到 本 地 后 重新 打 tag ° 


Locust 测 试 
请 求 统 计 
Median Average Min 
Method Name i E response response r 
requests failures p p oop 
time time time 
POST login 5070 78 59000 80551 11218 
POST /metrics 5114232 85879 63000 82280 29518 
None Total 5119302 85957 63000 82279 11218 
响应 时 间 分 布 
Name i 5090 669, 75% 80% 90% 9 
requests 
1m 5070 59000 125000 140000 148000 160000 16 
POST 
5114993 63000 127000 142000 149000 160000  16t 
/metrics 


None 5120063 63000 127000 142000 149000 160000  16t 


Total 
以 上 两 个 表格 都 是 肯 时 值 。 请 求 失败 率 在 2% 左 右 。 
Sample-webapp 起 了 48 个 pod ° 


Locust 模 拟 10 万 用 户 ， 每 秒 增长 100 个 。 


ü OQ CU SI Bind TT SLAVES RPS deese [| Reset Stats 
40 5140 2% 


AMODERN LOAD TESTING TOOL 10009 users 


Statistics 


POST llogin 5039 60000 202140 


POST /metrics 5076378 64000 331330 


Total 5081417 64000 331330 





图 片 - locust 测 试 页 面 


关于 Locust 的 使 用 请 参考 Github : https://github.com/rootsongjc/distributed-load- 
testing-using-kubernetes 


e AF Python 的 性 能 测试 工具 locust (4 LR 的 简单 对 比 ) 
e Locust docs 

e python] P fi KM iX T. : locust 

e Kubernetes 集 群 性 能 测试 

e CoreOS 是 如 何 将 Kubernetes 的 性 能 提高 10 倍 的 

e Kubernetes 1.3 的 性 能 和 弹性 一 ”2000 节点 ，60,0000 Pod 的 集群 
e 运用 Kubernetes 进 行 分 布 式 负载 测试 

e Kubemark User Guide 

e Flannel host-gw architecture 
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为 了 配置 kubernetes 中 的 traefik ingress 的 高 可 用 ， 对 于 kubernetes 和 集群 以 外 只 暴露 
一 个 访问 入 口 ， 需 要 使 用 keepalived 排 除 单 点 问题 。 本 文 参考 了 kube-keepalived- 
Vip， 但 并 没有 使 用 容器 方式 安装 ， 而 是 直接 在 node 节 点 上 安装 。 


AOL 

首先 解释 下 什么 叫 边缘 节点 〈Edge Node) ， 所 谓 的 边缘 节点 即 集群 内 部 用 来 向 集 
群 外 暴露 服务 能 力 的 节点 ， 集 群 外 部 的 服务 通过 该 节点 来 调用 集群 内 部 的 服务 ， 边 
缘 节 点 是 集群 内 外 交流 的 一 个 Endpoint 。 

边缘 节点 要 考虑 两 个 问题 


e 边缘 节点 的 高 可 用 ， 不 能 有 单 点 故障 ， 否 则 整个 kubernetes 集 群 将 不 可 用 
e 对 外 的 一 致 暴露 端口 ， 即 只 能 有 一 个 外 网 访问 IP 和 端口 


架构 
为 了 满足 边缘 节点 的 以 上 需求 ， 我 们 使 用 keepalived 来 实现 。 


在 Kubernetes 中 添加 了 service 的 同时 ， 在 DNS 中 增加 一 个 记录 ， 这 条 记录 需要 跟 
ingress 中 的 host 字段 相同 ，IP 地 址 即 VIP 的 地 址 ， 本 示例 中 


日 


是 172.20.0.119 ， 这 样 集群 外 部 就 可 以 通过 service 的 DNS 名 称 来 访问 服务 了 。 


选择 Kubernetes 的 三 个 node 作 为 边缘 节点 ， 并 安装 keepalived， 下 图 展示 了 边缘 节 
点 的 配置 ， 同 时 展示 了 向 Kubernetes 中 添加 服务 的 过 程 。 








Kubernetes edge node architecture 






| | PowerDNSsss 
(Add a item 


: Kubernetes 


C(DAdd a service 








Update 










Edge nodes Kubernetes cluster 
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图 片 - 边缘 节点 架构 


准备 

复 用 kubernetes 测 试 集群 的 三 台 主 机 。 
172.20.0.113 

172.20.0.114 


172.20.0.115 


安装 


使 用 keepalived 管 理 VIP，VIP 是 使 用 IPVS 创 建 的 ，IPVS 已 经 成 为 linux 内 核 的 模 
块 ， 不 需要 安装 


LVS 的 工作 原理 请 参 
考 : http://www.cnblogs.com/codebean/archive/2011/07/25/2116043.html 


不 使 用 镜像 方式 安装 了 ， 直 接手 动 安装 ， 指 定 三 个 节点 为 边缘 节点 (Edge 
node) ° 


因为 我 们 的 测试 集群 一 共 只 有 三 个 node， 所 有 在 在 三 个 node 上 都 要 安装 keepalived 
和 ipvsadmin ° 


yum install keepalived ipvsadm 


置 说 明 


需要 对 原先 的 traefik ingress 进 行 改 造 ， 从 以 Deployment 方 式 启动 改 成 
DeamonSet。 还 需要 指定 一 个 与 Node 在 同一 网 段 的 IP 地 址 作为 VIP， 我 们 指定 成 
172.20.0.119， 配 置 keepalived 前 需要 先 保 证 这 个 IP 没 有 被 分 配 。。 


e Traefik 以 DaemonSet 的 方式 启动 

e 通过 nodeSelector 选 择 边 缘 节 点 

e 通过 hostPort 暴 露 端口 

e 当前 VIP 漂 移 到 了 172.20.0.115 上 

e Traefik 根 据 访问 的 host 和 path 配 置 ， 将 流量 转发 到 相应 的 service 上 


配置 keepalived 


参考 基于 keepalived 实现 VIP 转移 ，lvs，nginx 的 高 可 用 ， 配 置 keepalived ° 
keepalived 的 官方 配置 文档 见 : http://keepalived.org/pdf/UserGuide.pdf 


忆 置 文件 /etc/keepalived/keepalived.conf 文件 内 容 如 下 


! Configuration File for keepalived 


global defs { 
notification_email { 
root@localhost 


notification_email_from kaadmin@localhost 
smtp_server 127.0.0.1 
smtp_connect_timeout 30 


router id LVS DEVEL 
} 


vrrp instance VI 1 { 

state MASTER 

interface ethO 

virtual router id 51 

priority 100 

advert int 1 

authentication ( 
auth type PASS 
auth pass 1111 

} 

virtual ipaddress { 
172.20.0.119 

} 


} 


virtual server 172.20.0.119 80{ 
delay_loop 6 
lb algo loadbalance 
lb kind DR 
nat mask 255.255.255.0 
persistence timeout 0 
protocol TCP 


real server 172.20.0.113 80( 
weight 1 
TCP CHECK { 
connect timeout 3 
} 

} 

real_server 172.20.0.114 80{ 
weight 1 
TCP_CHECK { 
connect_timeout 3 
} 

} 

real_server 172.20.0.115 80{ 
weight 1 


TCP_CHECK { 
connect timeout 3 


} 


Realserver 的 |P 和 端口 即 traefik 供 外 网 访问 的 |P 和 端口 。 


将 以 上 配置 分 别 拷贝 到 另外 两 台 node 的 /etc/keepalived 目录 下 。 


我 们 使 用 转发 效率 最 高 的 1b_kind DR 直接 路 由 方式 转发 ， 使 用 TCP_CHECK 来 
今 测 real_server 的 health 。 


设置 keepalived 为 开机 自 启动 


chkconfig keepalived on 


启动 keepalived 


systemctl start keepalived 


= € nodeAf @ z^ 1 keepalived > 3. Z&ethO IP > AE — Gnodet) X — 8 EX 3,— 
个 VIP 是 172.20.0.119 。 


$ ip addr show ethO 
2: eth0: «BROADCAST, MULTICAST, UP, LOWER UP» mtu 1500 qdisc mq sta 


te UP qlen 1000 
link/ether f4:e9:d4:9f:6b:a0 brd ff: ff: ff: fF: FF: FF 
inet 172.20.0.115/17 brd 172.20.127.255 scope global ethO 
valid lft forever preferred lft forever 
inet 172.20.0.119/32 scope global ethO 
valid lft forever preferred lft forever 


关 掉 拥有 这 个 VIP 主机 上 的 keepalived， 观 察 VIP 是 否 漂移 到 了 另外 两 台 主 机 的 其 中 
ee us 


改造 Traefik 


在 这 之 前 我 们 启动 的 traefik 使 用 的 是 deployment ， 只 启动 了 一 个 pod， 无 法 保证 高 
可 用 〈 即 需要 将 pod 固 定 在 某 一 台 主 机 上 ， 这 样 才 能 对 外 提供 一 个 唯一 的 访问 地 
dE) ， 现 在 使 用 了 keepalived 就 可 以 通过 VIP 来 访问 traefik， 同 时 启动 多 个 traefik 的 
pod 保 证 高 可 用 。 


置 文件 traefik.yaml 内 容 如 下 


apiVersion: extensions/vibeta1 
kind: DaemonSet 
metadata: 
name: traefik-ingress-lb 
namespace: kube-system 
labels: 
k8s-app: traefik-ingress-lb 
spec: 
template: 
metadata: 
labels: 
k8s-app: traefik-ingress-lb 
name: traefik-ingress-lb 
spec: 
terminationGracePeriodSeconds: 60 
hostNetwork: true 
restartPolicy: Always 
serviceAccountName: ingress 
containers: 
- image: traefik 
name: traefik-ingress-lb 
resources: 
limits: 
cpu: 200m 
memory: 30Mi 
requests: 
cpu: 100m 
memory: 20Mi 
ports: 
- name: http 
containerPort: 80 
hostPort: 80 
- name: admin 
containerPort: 8580 
hostPort: 8580 


- --web.address=: 8580 

- --kubernetes 
nodeSelector: 

edgenode: "true" 


注意 ， 我 们 使 用 了 nodeselector 选择 边缘 节点 来 调度 traefik-ingress-lb 运 行 在 它 
上 面 ， 所 有 你 需要 使 用 : 


kubectl label nodes 172.20.0.113 edgenode=true 
kubectl label nodes 172.20.0.114 edgenode=true 
kubectl label nodes 172.20.0.115 edgenode=true 


给 三 个 node 打 标签 。 


查看 DaemonSet 的 启动 情况 : 


$ kubectl -n kube-system get ds 


NAME DESIRED CURRENT READY UP-TO-DATE 
AVAILABLE NODE -SELECTOR AGE 
traefik-ingress-lb 3 3 3 3 

3 edgenode=true 2h 


现在 就 可 以 在 外 网 通过 172.20.0.119:80 来 访问 到 traefik ingress F ° 


使 用 域名 访问 Kubernetes 中 的 服务 


现在 我 们 已 经 部 署 了 以 下 服务 : 


e 三 个 边缘 节点 ， 使 用 Traefik 作 为 Ingress controller 
e 使 用 keepalived 做 的 VIP (虚拟 IP) 172.20.0.119 


这 样 在 访问 该 IP 的 时 候 通 过 指定 不 同 的 Host 来 路 由 到 kubernetes 后 端 服务 。 这 种 
方式 访问 每 个 Service 时 都 需要 指定 Host ， 而 同一 个 项 目 中 的 服务 一 般 会 在 同一 
个 Ingress 中 配置 ， 使 用 Path 来 区 分 Service 已 经 足够 ， 这 时 候 只 要 为 

VIP (172.20.0.119) 来 配置 一 个 域名 ， 所 有 的 外 部 访问 直接 通过 该 域名 来 访问 即 
可 o 


如 下 图 所 示 : 













Ingredient 
- Traefik 
- Ingress 


Accessing kubernetes services with DNS name 


- Keepalived 
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AA -使 用 域名 来 访问 Kubernetes 中 的 服务 


参考 


kube-keepalived-vip 

http://www.keepalived.org/ 

keepalived 工 作 原 理 与 配置 说 明 

LVS 简 介 及 使 用 

基于 keepalived 实现 VIP 转移 ，Ilvs，nginx 的 高 可 用 
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J+ " m 
x x Nginx ingress 
Nginx ingress 使 用 ConfigMap 来 管理 Nginx 配 置 ，nginx 是 大 家 熟知 的 代理 和 负载 均 
衡 软 件 ， 比 起 Traefik 来 说 功能 更 加 强大 . 


我 们 使 用 helm 来 部 署 ，chart 保 存在 私有 的 仓库 中 ， 请 确保 您 已 经 安装 和 配置 好 
helm ，helm 安 装 使 用 见 使 用 Helm 管 理 kubernetes 应 用 。 


镜像 准备 
安装 时 需要 用 到 的 镜像 有 : 


e sophos/nginx-vts-exporter:v0.6 
e gcr.io/google_containers/nginx-ingress-controller:0.9.0-beta.15 
e gcr.io/google_containers/defaultbackend:1.3 


gcr.io 中 的 那个 两 个 镜像 我 复制 了 一 份 到 时 速 云 ， 可 供 大 家 下 载 : 


e index.tenxcloud.com/jimmy/defaultbackend:1.3 
e index.tenxcloud.com/jimmy/nginx-ingress-controller:0.9.0-beta.15 


Docker hub 上 的 那个 镜像 可 以 直接 下 载 ， 所 有 的 安装 时 需要 的 配置 保存 
4z.../manifests/nginx-ingress B 3& F » 


步 又 详解 
安装 nginx-ingress chart 到 本 地 repo 中 


修改 values.yaml 配置 ， 启 用 RBAC 支 持 ， 相 关 配 置 见 nginx-ingress chart。 


helm package . 


2- f niginx-ingress 


$ helm search nginx-ingress 


NAME VERSION DESCRIPTION 
local/nginx-ingress 0.8.9 An nginx Ingress controller t 
hat uses ConfigMap... 

stable/nginx-ingress 0.8.9 An nginx Ingress controller t 
hat uses ConfigMap... 

stable/nginx-lego 0.3.0 Chart for nginx-ingress-contr 


oller and kube-lego 


1& M helm? 4 nginx-ingress 


$ helm install --name nginx-ingress local/nginx-ingress 
NAME : nginx-ingress 

LAST DEPLOYED: Fri Oct 27 18:26:58 2017 

NAMESPACE: default 

STATUS: DEPLOYED 


RESOURCES: 

==> rbac.authorization.k8s.io/vibeta1/Role 

NAME KIND 

nginx-ingress-nginx-ingress Role.vibeta1.rbac.authorization.k8s 
. io 


==> rbac.authorization.k8s.io/vibeta1/RoleBinding 
nginx-ingress-nginx-ingress RoleBinding.vibeta1.rbac.authorizat 
ion.k8s.io 


==> vi/Service 


NAME CLUSTER- IP EXT 
ERNAL-IP  PORT(S) AGE 
nginx-ingress-nginx-ingress-controller 10.254.100.108 «no 
des» 80:30484/TCP,443:31053/TCP 1s 
nginx-ingress-nginx-ingress-default-backend 10.254.58.156 «no 
ne> 80/TCP 1s 


==> extensions/vibeta1/Deployment 


NAME DESIRED CURRENT U 

P-TO-DATE AVAILABLE AGE 

nginx-ingress-nginx-ingress-default-backend 1 1 1 
0 1s 

nginx-ingress-nginx-ingress-controller 1 1 1 
0 1s 


==> vi/ConfigMap 
NAME DATA AGE 
nginx-ingress-nginx-ingress-controller 1 1s 


==> vi/ServiceAccount 
NAME SECRETS AGE 
nginx-ingress-nginx-ingress 1 1s 


==> rbac.authorization.k8s.io/vibetai1/ClusterRole 

NAME KIND 

nginx-ingress-nginx-ingress ClusterRole.vibeta1.rbac.authorizat 
ion.k8s.io 


==> rbac.authorization.k8s.io/vibeta1/ClusterRoleBinding 
nginx-ingress-nginx-ingress ClusterRoleBinding.vibeta1.rbac.aut 
horization.k8s.io 


NOTES: 
The nginx-ingress controller has been installed. 
Get the application URL by running these commands: 

export HTTP_NODE_PORT=$(kubectl --namespace default get servic 
es -o jsonpath="{.spec.ports[0].nodePort}" nginx-ingress-nginx-i 
ngress-controller ) 

export HTTPS_NODE_PORT=$(kubectl --namespace default get servi 
ces -0 jsonpath="{.spec.ports[1].nodePort}" nginx-ingress-nginx- 
ingress-controller) 

export NODE IP-$(kubectl --namespace default get nodes -o json 
path="{.items[0].status.addresses[1].address}") 


echo "Visit http://$NODE_IP:$HTTP_NODE_PORT to access your app 
lication via HTTP." 

echo "Visit https://$NODE_IP:$HTTPS_NODE_PORT to access your a 
pplication via HTTPS." 


An example Ingress that makes use of the controller: 


apiVersion: extensions/vibetai 
kind: Ingress 
metadata: 
annotations: 
kubernetes.io/ingress.class: nginx 
name: example 
namespace: foo 


spec: 
rules: 
- host: www.example.com 
http: 
paths: 
- backend: 


serviceName: exampleService 
servicePort: 80 
path: / 
# This section is only required if TLS is to be enabled for 
the Ingress 
tls: 
- hosts: 
- www.example.com 
secretName: example-tls 


If TLS is enabled for the Ingress, a Secret containing the certi 
ficate and key must also be provided: 


apiVersion: vi 
kind: Secret 
metadata: 
name: example-tls 
namespace: foo 
data: 
tls.crt: «base64 encoded cert» 
tls.key: «base64 encoded key» 
type: kubernetes.io/tls 


t% e] Nginx 


首先 获取 Nginx 的 地 址 ， 从 我 们 使 用 helm 安 装 nginx-ingress 命 令 的 输出 中 那个 可 以 
看 到 提示 ， 根 据 提 示 执 行 可 以 看 到 nginx 的 http 和 https 地 址 : 


export HTTP_NODE_PORT=$(kubectl --namespace default get servic 
es -o jsonpath="{.spec.ports[0].nodePort}" nginx-ingress-nginx-i 
ngress-controller ) 

export HTTPS_NODE_PORT=$(kubectl --namespace default get servi 
ces -0 jsonpath="{.spec.ports[1].nodePort}" nginx-ingress-nginx- 
ingress-controller ) 

export NODE_IP=$(kubectl --namespace default get nodes -o json 
path="{.items[0].status.addresses[1].address}") 


echo "Visit http://$NODE_IP:$HTTP_NODE_PORT to access your app 
Ligation via HTTP." 

echo "Visit https://$NODE IP:$HTTPS NODE PORT to access your a 
pplication via HTTPS.” 

Visit http://172.20.0.113:30484 to access your application via 

HTTP. 

Visit https://172.20.0.113:31053 to access your application vi 
a HTTPS. 


。http 地 址 : http://172.20.0.113:30484 
e https 地 址 : https://172.20.0.113:31053 


我 们 分 别 在 http 和 https 地 址 上 测试 一 下 : 


e /healthz 返回 200 
e / 返回 404 错 误 


curl -v http://172.20.0.113:30484/healthz 

# 返回 200 

curl -v http://172.20.0.113:30484/ 

+ 返回 404 

curl -v --insecure http://172.20.0.113:30484/healthz 
# 返回 200 

curl -v --insecure http://172.20.0.113:30484/ 


/ 返回 404 


删除 nginx-ingress 


helm delete --purge nginx-ingress 


使 用 --purge #27 A fh RM releases E Fick > UTERE A AR fié 
使 用 重 名 的 release ° 


e Ingress-nginx github 
e Nginx chart configuration 
e 4% A Helm #kubernetes = Jf] 
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ET 
4C At a DNS 

DNS 组 件 作 为 Kubernetes 中 服务 注册 和 发 现 的 一 个 必要 组 件 ， 起 着 举足轻重 的 作 
用 ， 是 我 们 在 安装 好 Kubernetes 集群 后 部 署 的 第 一 个 容器 化 应 用 。 
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安装 配置 kube-dns 


在 我 们 安装 Kubernetes 集 群 的 时 候 就 已 经 安装 了 kube-dns 插 件 ， 这 个 插件 也 是 官方 
推荐 安装 的 。 通 过 将 Service 注册 到 DNS 中 ，Kuberentes 可 以 为 我 们 提供 一 种 简 
单 的 服务 注册 发 现 与 负载 均衡 方式 。 

CoreDNS 作 为 CNCF 中 的 托管 的 一 个 项 目 ， 在 Kuberentes1.9 版 本 中 ， 使 用 


kubeadm 方 式 安装 的 集群 可 以 通过 以 下 命令 直接 安装 CoreDNS 。 


kubeadm init --feature-gates=CoreDNS=true 


您 也 可 以 使 用 CoreDNS 替 换 Kubernetes 插 件 kube-dns， 可 以 使 用 Pod 部 署 也 可 以 
独立 部 署 ， 请 参考 Using CoreDNS for Service Discovery， 下 文 将 介绍 如 何 配置 
kube-dns ° 


kube-dns 


kube-dns 是 Kubernetes 中 的 一 个 内 置 插件 ， 目 前 作为 一 个 独立 的 开源 项 目 维护 ， 见 
https://github.com/kubernetes/dns ° 


下 文中 给 出 了 配置 DNS Pod 的 提示 和 定义 DNS 解析 过 程 以 及 诊断 DNS 问题 的 指 
dj o 


前 提要 求 


e Kubernetes 1.6 及 以 上 版 本 。 
e 集群 必须 使 用 kube-dns 插件 进行 配置 。 


kube-dns 介绍 


从 Kubernetes v1.3 版 本 开始 ， 使 用 cluster add-on 插件 管理 器 回 自动 启动 内 置 的 
DNS ° 


Kubernetes DNS pod 中 包括 3 个 容器 : 


e kubedns : kubedns 进程 监视 Kubernetes master 中 的 Service 和 
Endpoint 的 变化 ， 并 维护 内 看 查 找 结 构 来 服务 DNS 请 求 。 
e dnsmasq : dnsmasq 容器 添加 DNS 缓存 以 提高 性 能 。 
e sidecar : sidecar 容器 在 执行 双重 健康 检查 (针对 dnsmasq 和 
kubedns ) 时 提供 单个 健康 检查 端点 (监听 在 10054 端 口 ) 。 


DNS pod 有 具有 静态 IP 并 作为 Kubernetes 服务 暴露 出 来 。 该 静态 IP 分 配 后 ， 
kubelet 会 将 使 用 --cluster-dns = <dns-service-ip> 标志 配置 的 DNS 传递 
给 每 个 容器 。 


DNS 名 称 也 需要 域名 。 本 地 域 可 以 使 用 标志 --cluster-domain = <default- 
local-domain> 在 kubelet 中 配置 。 


Kubernetes 集 群 DNS 服 务 器 基于 SkyDNS 库 。 它 支持 正 向 查找 (ABR) ， 服 务 
查找 (SRV 记录 ) 和 反 向 IP 地 址 查找 (PTR 记录) 


kube-dns 支持 的 DNS 格式 


kube-dns 将 分 别 为 service 和 pod 生成 不 同 格式 的 DNS 记录 。 
Service 
e A 记录 : 生成 my-svc.my-namespace.svc.cluster.local 域名 ， 解 析 成 IP 
地 址 ， 分 为 两 种 情况 : 
o 普通 Service : 解析 成 ClusterlP 
o Headless Service : 解析 为 指定 Pod 的 IP 列表 
e SRV 记 录 : 为 命名 的 端口 (普通 Service 或 Headless Service) 生成 _my- 
port-name. my-port-protocol.my-svc.my- 


namespace.svc.cluster.local 的 域名 
Pod 


e A 记录 : 生成 域名 pod-ip.my-namespace.pod.cluster.local 


kube-dns 存根 域名 


可 以 在 Pod 中 指定 hostname 和 subdomain : hostname.custom- 


subdomain.default.svc.cluster.local ， 例 如 : 


apiVersion: v1 
kind: Pod 
metadata: 
name: busybox 
labels: 
name: busybox 
spec: 
hostname: busybox-1 
subdomain: busybox-subdomain 
containers: 
name: busybox 
- image: busybox 
command: 
- sleep 
_ "3600"! 


该 Pod 的 域名 是 busybox-1.busybox- 


subdomain.default.svc.cluster.local ° 


继承 节点 的 DNS 


运行 Pod 时 ，kubelet 将 预先 配置 集群 DNS 服务 器 到 Pod 中 ， 并 搜索 节点 自己 的 
DNS 设置 路 径 。 如 果 节 点 能 够 解析 特定 于 较 大 环境 的 DNS 名 称 ， 那 么 Pod 应 该 也 
能 够 解析 。 请 参阅 下 面 的 已 知 问题 以 了 解 整 告 。 


如 果 您 不 想 要 这 个 ， 或 者 您 想 要 为 Pod 设置 不 同 的 DNS 配置 ， 您 可 以 给 kubelet 
指定 --resolv-conf 标志 。 将 该 值 设置 为 "" 意味 着 Pod 不 继承 DNS。 将 其 设 
置 为 有 效 的 文件 路 径 意味 着 kubelet 将 使 用 此 文件 而 不 是 /etc/resolv.conf 用 
于 DNS 继承 。 


配置 存根 域 和 上 游 DNS 服务 器 


通过 为 kube-dns ( kube-system:kube-dns ) 提供 一 个 ConfigMap， 集 群 管理 
员 能 够 指定 自 定义 存根 域 和 上 游 nameserver » 


由 


~ 


例如 ， 下 面 的 ConfigMap 建立 了 一 个 DNS 配置 ， 它 具有 一 个 单独 的 存根 域 和 两 个 
上 游 nameserver : 


apiVersion: v1 
kind: ConfigMap 
metadata: 
name: kube-dns 
namespace: kube-system 


data: 
stubDomains: | 
{“acme. local”: [“1.2.3.4”]} 
upstreamNameservers: | 


[^8.8.8.B*, *8.8.4.4"] 


如 上 面 指定 的 那样 ， 带 有 "“.acme.locap" 后 组 的 DNS 请 求 被 转发 到 1.2.3.4 处 监听 的 
DNS ° Google Public DNS 为 上 游 查询 提供 服务 。 


下 表 描 述 了 如 何 将 具有 特定 域名 的 查询 映射 到 其 目标 DNS 服务 器 : 


域名 响应 查询 的 服务 器 
kubernetes.default.svc.cluster.local kube-dns 
foo.acme.local a x DNS (1.2.3.4) 
widget.com 上 游 DNS (8.8.8.8 或 8.8.4.4) 


查看 ConfigMap 选项 获取 更 多 关于 配置 选项 格式 的 详细 信息 


自 定义 的 上 游 名 称 服务 器 和 存根 域 不 会 影响 那些 将 自己 的 dnsPolicy 设置 为 
Default 或 者 None 的 Pod。 


如 果 Pod 的 dnsPolicy 设置 为 “ClusterFirst ”， 则 其 名 称 解 析 将 按 其 他 方式 
处 理 ， 具 体 取 决 于 存根 域 和 上 游 DNS 服务 器 的 配置 


未 进行 自 定义 配置 : 没有 匹配 上 配置 的 集群 域名 后 组 的 任何 请 求 ， 例 如 
“www.kubernetes.io”， 将 会 被 转发 到 继承 自 节点 的 上 游 nameserver 。 


进行 自 定 义 配 置 : 如 果 配 置 了 存根 域 和 上 游 DNS 服务 器 (和 在 前 面 例子 配置 的 一 
样 ) ， DNS 查询 将 根据 下 面 的 流程 进行 路 由 : 


查询 首先 被 发 送 到 kube-dns 中 的 DNS RAB 
2. 从 缓存 层 ， 检 查 请 求 的 后 级 ， 并 转发 到 合适 的 DNS 上 ， 基 于 如 下 的 示例 : 


o 具有 集群 后 级 的 名 字 (例如 “.clusterlocal”) : 请 求 被 发 送 到 kube-dns ° 


o 具有 存根 域 后 组 的 名 字 (例如 “acme.local") : 请 求 被 发 送 到 配置 的 自 定 
SL DNS 解析 器 (例如: 监听 在 1.2.3.4) 。 

o 不 具有 能 匹配 上 后 组 的 名 字 (例如 “widget.com”) : 请 求 被 转发 到 上 游 
DNS (例如 : Google 公共 DNS 服务 器 ，8.8.8.8 和 8.8.4.4) ° 


kube-dns | 


LI 











upstream DNS yea md kube-dns 
(8.8.8.8, 8.8.4.4) ; (1.2 3 4) * cluster.local. 





= <= * 


DNS cache Ea 
(dnsmasq) i 
F 


Pod 
dnsPolicy: ClusterFirst 


E A - DNS lookup flow 





sidecar 











ConfigMap 选项 


kube-dns kube-system:kube-dns ConfigMap 的 选项 如 下 所 示 : 


字段 格式 描述 
使 用 DNS 后 组 目标 nameserver 可 能 是 
key 的 JSON 一 个 Kubernetes 
map (例如 Service。 例 如 ， 可 以 运 
stubDomains (可 选 ) “acme.local”) > 474 G4) dnsmasq 副 


以 及 DNS IP 的 本 ， 将 DNS 4 FRE! 
JSON 数组 作为 ClusterDNS namespace 
value。 中 。 


注意 : 如 果 指 定 ， 则 指定 
的 值 会 替换 掉 被 默认 从 节 
点 的 

/etc/resolv.conf 中 
获取 到 的 nameserver » 
限制 : 最 多 可 以 指定 三 个 
上 游 nameserver ° 


upstreamNameservers (可 DNSIP 的 
选 ) JSON 数组 。 


示例 


示例 : 存根 域 


在 这 个 例子 中 ， 用 户 有 一 个 Consul DNS 服务 发 现 系统 ， 他 们 希望 能 够 与 kube- 
dns 集成 起 来 。 Consul 域名 服务 器 地 址 为 10.150.0.1， 所 有 的 Consul 名 字 具 iud 
级 .consul.local 。 要 配置 Kubernetes， 集 群 管理 员 只 需要 简单 地 创建 
ConfigMap 对 象 ， 如 下 所 示 : 


apiVersion: v1 
kind: ConfigMap 
metadata: 

name: kube-dns 

namespace: kube-system 
data: 

stubDomains: | 

4 consul, local”: [*20.158.8.1"]) 


注意 ， 集 群 管理 员 不 希望 覆盖 节点 的 上 游 nameserver， 所 以 他 们 不 会 指定 可 选 的 


upstreamNameservers 字段 。 


示例 : 上 游 nameserver 


在 这 个 示例 中 ， 集 群 管理 员 不 希望 显 式 地 强制 所 有 非 集群 DNS 查询 进入 到 他 们 自 
己 的 nameserver 172.16.0.1。 而 且 这 很 容易 他 们 只 需要 创建 一 个 
ConfigMap * upstreamNameservers 字段 指定 期 望 的 nameserver PPT ° 


apiVersion: vi 
kind: ConfigMap 
metadata: 
name: kube-dns 
namespace: kube-system 
data: 
upstreamNameservers: | 
[45172.415.8.1*] 


调试 DNS 解析 
创建 一 个 简单 的 Pod 用 作 测 试 环境 


创建 一 个 名 为 busybox.yaml 的 文件 ， 其 中 包括 以 下 内 容 : 


apiVersion: vi 
kind: Pod 
metadata: 

name: busybox 

namespace: default 

spec: 

containers: 

- name: busybox 
image: busybox 
command: 

- sleep 
_ "2600"! 
imagePullPolicy: IfNotPresent 
restartPolicy: Always 


使 用 该 文件 创建 Pod 并 验证 其 状态 : 
$ kubectl create -f busybox.yaml pod "busybox" created 


$ kubectl get pods busybox NAME READY STATUS RESTARTS AGE busybox 
1/1 Running 0 


该 Pod 运行 后 ， 您 可 以 在 它 的 环境 中 执行 “nslLookup `。 如 果 您 看 到 类 似 如 下 的 输出 
， 表示 DNS 正在 正确 工作 。 


`` bash 
$ kubectl exec -ti busybox -- nslookup kubernetes.default 
Server: 10.0.0.10 


Address 1: 10.0.0.10 


Name: kubernetes.default 
Address 1: 10.0.0.1 


如 果 nslookup 命令 失败 ， 检 查 如 下 内 容 : 


首先 检查 本 地 DNS 配置 


查看 下 resolv.conf 文件 。 (参考 集成 节点 的 DNS 和 下面 的 已 知 问题 获取 更 多 信 
息 ) 


$ kubectl exec busybox cat /etc/resolv.conf 


: 


验证 搜索 路 径 和 名 称 服务 器 设置 如 下 (请 注意 ， 搜 索 路 径 可 能 因 不 同 的 云 提 供 商 而 
F) 


search default.svc.cluster.local svc.cluster.local cluster.local 
google.internal c.gce_project_id.internal 

nameserver 10.0.0.10 

options ndots:5 


如 果 看 到 如 下 错误 表明 错误 来 自 kube-dns 或 相关 服务 : 


$ kubectl exec -ti busybox -- nslookup kubernetes.default 
Server: 10.0.0.10 
Address 1: 10.0.0.10 


nslookup: can't resolve 'kubernetes.default' 


或 者 
$ kubectl exec -ti busybox -- nslookup kubernetes.default 
Server: 10.0.0.10 


Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local 


nslookup: can't resolve 'kubernetes.default' 


检查 DNS pod 有 是否 在 运行 
使 用 kubectl get pods 命令 验证 DNS pod 是 否 正 在 运行 。 


$ kubectl get pods --namespace-kube-system -1 k8s-app-kube-dns 
NAME READY STATUS RESTARTS AGE 


kube-dns-v19-ezoiy 3/3 Running 0 1h 


如 果 您 看 到 没有 Pod 运行 或 者 Pod 处 于 失败 /完成 KA ^ DNS 插件 可 能 没有 部 署 
到 您 的 当前 环境 中 ， 您 需要 手动 部 署 。 


检查 DNS pod 中 的 错误 


使 用 kubectl logs 命令 查看 DNS 守护 进程 的 日 志 。 


$ kubectl logs --namespace=kube-system $(kubectl get pods --name 
space=kube-system -1 k8s-app=kube-dns -o name) -c kubedns 
$ kubectl logs --namespace=kube-system $(kubectl get pods --name 
space=kube-system -1 k8s-app=kube-dns -o name) -c dnsmasq 
$ kubectl logs --namespace-kube-system $(kubectl get pods --name 
space=kube-system -1 k8s-app=kube-dns -o name) -c sidecar 


看 看 有 没有 可 疑 的 日 志 。 以 字母 “W”，“E”，“ FF ”开头 的 代表 敬告、 错误 和 失 
败 。 请 搜索 具有 这 些 日 志 级 别 的 条 目 ， 并 使 用 kubernetes issues 来 报告 意外 错误 


o 


DNS 服务 启动 了 吗 ? 


使 用 kubectl get service 命令 验证 DNS 服务 是 否 启 动 。 
$ kubectl get svc --namespace=kube-system 
NAME CLUSTER- IP EXTERNAL - IP PORT(S) A 
GE 
kube-dns 10.0.0.10 «none» 53/UDP, 53/TCP 
1h 


如 果 您 已 经 创建 了 该 服务 或 它 本 应 该 默认 创建 但 没有 出 现 ， 参 考 调 试 服务 获取 更 多 
信息 。 


x aE +$ 
DNS ñ AI E HK T? 
您 可 以 使 用 kubectl get endpoints 命令 验证 DNS 端点 是 否 被 暴露 。 


$ kubectl get ep kube-dns --namespace=kube-system 
NAME ENDPOINTS AGE 
kube-dns 10.180.3.17:53,10.180.3.17:53 1h 


如 果 您 没有 看 到 端点 ， 查 看 调试 服务 文档 中 的 端点 部 分 。 


获取 更 多 的 Kubernetes DNS 示例 ， 请 参考 Kubernetes GitHub 仓库 中 的 cluster- 
dns 示例 。 


已 知 问 题 


Kubernetes #3 装 时 不 会 将 节点 的 resolv.conf 文件 配置 为 默认 使 用 集群 DNS ， 因 为 
过 程 本 身 是 特定 于 发 行 版 的 。 这 一 步 应 该 放 到 最 后 实现 。 


Linux 的 libc 不 可 思议 的 卡 住 (查看 该 2005 年 起 暴 出 来 的 bug) 限制 只 能 有 3 个 
DNS nameserver 记录 和 6 个 DNS search 记录 。Kubernetes 需要 消耗 1 个 
nameserver 记录 和 3 个 search 记录 。 这 意味 着 如 果 本 地 安装 已 经 使 用 3 个 
nameserver 或 使 用 3 个 以 上 的 search 记录， 那么 其 中 一 些 设置 将 会 去 失 。 
有 个 部 分 解决 该 问题 的 方法 ， 就 是 节点 可 以 运行 dnsmasq ， 它 将 提供 更 多 的 
nameserver 条 目 ， ONU. 的 search 条 目 。 您 也 可 以 使 用 kubelet 的 


--resolv-conf 标志 。 


如 果 您 使 用 的 是 Alpine 3.3 或 更 低 版 本 作为 基础 映像 ， 由 于 已 知 的 Alpine 问题 ， 
DNS 可 能 无 法 正常 工作 。 点 击 这 里 查看 更 多 信息 。 


Kubernetes 集群 联邦 (多 可 用 区 支持 ) 


Kubernetes 1.3 版 本 起 引入 了 支持 多 站 点 Kubernetes 安装 的 集群 联邦 支持 。 

要 对 Kubernetes 集群 DNS 服务 器 处 理 DNS 查询 的 方式 进行 一 些小 的 ee PA 
8j) 更 改 ， 以 便于 查找 联邦 服务 ( 跨 多 个 Kubernetes 集群 ) 。 有 关 集 群 联 邦和 多 
站 点 支持 的 更 多 详细 信息 ， 请 参阅 集群 联邦 管理 员 指 南 。 


e Configure DNS Service 

e Service 和 Pod 的 DNS 

e 自动 扩容 集群 中 的 DNS 服务 

e Using CoreDNS for Service Discovery 
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安装 配置 CoreDNS 


CoreDNS 可 以 在 具有 标准 的 Kube-DNS 的 Kubernetes 集 群 中 运行 。 作 为 Kubernetes 
的 插件 使 用 ，CoreDNS 将 从 Kubernetes 集 群 中 读 取 区 (zone) 数据 。 它 实现 了 为 
Kubernetes 的 DNS 服 务 发 现 定义 的 规范 : Kubernetes DNS-Based Service 
Discovery ° 


部 署 CoreDNS 


部 署 CoreDNS 需要 使 用 到 官方 提供 的 两 个 文件 deploy.sh 和 coredns.yaml.sed (这 
两 个 文件 已 经 放 入 manifest 的 coredns 中 ) 


deploy.sh 是 一 个 用 于 在 已 经 运行 kube-dns 的 集群 中 生成 运行 CoreDNS 部 署 文 
件 (manifest) 的 工具 脚本 。 它 使 用 coredns.yaml.sed 文件 作为 模板 ， 创 建 一 
个 ConfigMap 和 CoreDNS 的 deployment， 然 后 更 新 集群 中 已 有 的 kube-dns 服务 的 
selector 使 用 CoreDNS 的 deployment。 重 用 已 有 的 服务 并 不 会 在 服务 的 请 求 中 发 生 


冲突 。 


deploy.sh 文件 并 不 会 删除 kube-dns 的 deployment 或 者 replication controller。 如 
果 要 删除 kube-dns， 你 必须 在 部 署 CoreDNS 后 手动 的 删除 kube-dns。 


你 需要 仔细 测试 manifest 文 件 ， 以 确保 它 能 够 对 你 的 集群 正常 运行 。 这 依赖 于 你 的 
怎样 构建 你 的 集群 以 及 你 正在 运行 的 集群 版 本 。 对 manifest 文 件 做 一 些 修 改 是 有 上 比 
要 的 。 


在 最 佳 的 案例 场景 中 ， 使 用 CoreDNS 替 换 Kube-DNS 只 需要 使 用 下 面 的 两 个 命令 : 


$ ./deploy.sh | kubectl apply -f - 
$ kubectl delete --namespace-kube-system deployment kube-dns 


注意 : 我 们 建议 在 部 署 CoreDNS 后 删除 kube-dns。 否 则 如 果 CoreDNS 和 kube-dns 
同时 运行 ， 服 务 查 询 可 能 会 随机 的 在 CoreDNS 和 kube-dns 之 间 产 生 。 
对 于 非 RBAC 部 署 ， 你 需要 编辑 生成 的 结果 yaml 文 件 : 


1. 从 yaml 文 件 的 Deployment 部 分 删除 serviceAccountName: coredns 


2. 删除 ServiceAccount ^ ClusterRole 和 ClusterRoleBinding 部 分 


> 


5 


e Kubernetes DNS-Based Service Discovery 
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运 维 管理 


将 集群 部 署 到 生产 环境 后 就 不 得 不 考虑 运 维 管理 问题 。 运 维 管理 问题 主要 包括 如 下 
几 个 方面 : 


监控 : 包括 kubernetes 本 身 组 件 和 Pod、 应 用 的 监控 
e 日 志 收 集 : 包括 kubernetes 本 身 组 件 的 日 志 ， 应 用 的 日 志 
e 审计 : 用 户 对 集群 操作 的 审计 
e 安全 : 用 户 权 限 的 管理 和 镜像 漏洞 扫描 
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Master? 447 Jf] 


作者 : mendickxiao 


经 过 部 署 Kubernetes 集 群 章节 我 们 已 经 可 以 顺利 的 部 署 一 个 集群 用 于 开发 和 测试 ， 
但 是 要 应 用 到 生产 就 就 不 得 不 考虑 master 节 点 的 高 可 用 问题 ， 因 为 现在 我 们 的 
master 节 点 上 的 几 个 服务 kube-apiserver 、 kube-scheduler 和 kube- 
controller-manager 都 是 单 点 的 而 且 都 位 于 同一 个 节点 上 ， 一 旦 master 节 点 宕 
机 ， 虽 然 不 应 答 当 前 正在 运行 的 应 用 ， 将 导致 Kubernetes 集 群 无 法 变更 。 本 文 将 引 
导 你 创建 一 个 高 可 用 的 master 节 点 。 


在 大 神 gzmzj 的 ansible 创 建 kubernetes 集 群 神 作 中 有 讲 到 如 何 配 置 多 个 Master， 但 
是 在 实践 过 程 中 还 是 遇 到 不 少 坑 。 需 要 将 坑 填 上 才能 工作 。 神 作 链接 地 址 : 集群 规 
划 和 基础 参数 设 定 。 


按照 神 作 的 描述 ， 实 际 上 是 通过 keepalived + haproxy 实 现 的 ， 其 中 keepalived 是 提 
供 一 个 VIP， 通 过 VIP 关联 所 有 的 Master 节 点 ; 然后 haproxy 提 供 端 口 转发 功能 。 由 
于 VIP 还 是 存在 Master 的 机 器 上 的 ， 默 认 配 置 API Server 的 端口 是 6443， 所 以 我 们 
需要 将 另外 一 个 端口 关联 到 这 个 VIP 上 ， 一 般 用 8443 。 


Client Kubectl 


VIP:8443 


8443 


6443 
Mater 


8443 


6443 
Mater 


API Server 
Keep-alived - VIP 


Keep-alived - VIP 





图 片 - Master HA 架构 图 


根据 神 作 的 实践 ， 我 发 现 需要 在 Master 手 工 安装 keepalived, haproxy ° 


yum install keepalived 
yum install haproxy 


需要 将 HAProxy 黑 认 的 配置 文件 balance 从 source 修 改 为 roundrobin 方式 。 
haproxy 的 配置 文件 haproxy.cfg 默认 路 径 是 /etc/haproxy/haproxy.cfg ° J 
外 需要 手工 创建 /run/haproxy 的 目录 ， 和 否则 haproxy 会 启动 失败 。 


e bind 绑 定 的 就 是 VIP 对 外 的 端口 号 ， 这 里 是 8443 © 


e balance 指 定 的 负载 均衡 方式 是 roundrobin 方式 ， 黑 认 是 Source 方式 。 在 我 
的 测试 中 ，source 方 式 不 工作 。 

e Server 指 定 的 就 是 实际 的 Master 节 点 地 址 以 及 引 正 工作 的 端口 号 ， 这 里 是 
6443。 有 多 少 台 Master 就 写 多 少 条 记录 。 


# haproxy.cfg sample 


global 
log /dev/log localo 
log /dev/log locali notice 
chroot /var/lib/haproxy 
*stats socket /run/haproxy/admin.sock mode 660 level adm 
in 
stats timeout 30s 
user haproxy 
group haproxy 
daemon 
nbproc 1 
defaults 
log global 


timeout connect 5000 
timeout client 50000 
timeout server 50000 


listen kube-master 

**bind 0.0.0.0:8443** 

mode tcp 

option tcplog 

**balance roundrobin** 

server si **Master 1 的 IP 地 址 **:6443 check inter 10000 fa 
ll 2 rise 2 weight 1 

server s2 **Master 2 的 IP 地 址 **:6443 check inter 10000 fa 
ll 2 rise 2 weight 1 


修改 keepalived 的 配置 文件 ， 配 置 正 确 的 VIP。keepalived 的 配置 文 
fF keepalived.conf 的 默认 路 径 是 /etc/keepalived/keepalived.conf 


e priority 决 定 哪个 Master 是 主 ， 哪 个 Master 是 次 。 数 字 小 的 是 主 ， 数 字 大 的 是 
次 。 数 字 越 小 优先 级 越 高 。 

e virtual router id 决定 当前 VIP 的 路 由 号 ， 实 际 上 VIP 提供 了 一 个 虚拟 的 路 
由 功能 ， 该 VIP 在 同一 个 子 网 内 必须 是 唯一 。 

e virtual ipaddress 提 供 的 就 是 VIP 的 地 址 ， 该 地 址 在 子 网 内 必须 是 空闲 未 必 分 配 
的 。 


# keepalived.cfg sample 


global_defs { 
router id lb-backup 
j 


vrrp instance VI-kube-master ( 

state BACKUP 

**priority 110** 

dont track primary 

interface ethO 

**yirtual router id 51** 

advert int 3 

virtual ipaddress ( 
**10.86.13.36** 

} 


配置 好 后 ， 那 么 先 尼 动 主 Master 的 keepalived 和 haproxy。 


systemctl enable keepalived 
systemctl start keepalived 
systemctl enable haproxy 
systemctl start haproxy 


然后 使 用 ip a s 命 令 查看 是 否 有 VIP 地 址 分 配 。 如 果 看 到 VIP 地 址 已 经 成 功 分 配 在 
eth0 网 卡 上 ， 说 明 keepalived 启 动 成 功 。 


[rootQkube32 ~]# ipa s 
1: lo: «LOOPBACK, UP,LOWER UP» mtu 65536 qdisc noqueue state UNKN 
OWN qlen 1 
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 
inet 127.0.0.1/8 scope host lo 
valid lft forever preferred_lft forever 
inet6 ::1/128 scope host 
valid lft forever preferred lft forever 
2: eth0: «BROADCAST, MULTICAST, UP, LOWER UP» mtu 1500 qdisc mq sta 
te UP qlen 1000 
link/ether 00:50:56:a9:d5:be brd ff:ff:ff:ff:ff:ff 
inet 10.86.13.32/23 brd 10.86.13.255 scope global ethO 
valid lft forever preferred lft forever 
**inet 10.86.13.36/32 scope global eth0** 
valid lft forever preferred lft forever 
inet6 fe80::250:56ff:fea9:d5be/64 scope link 
valid lft forever preferred lft forever 


更 保险 方法 还 可 以 通过 systemctl status keepalived -1 看 看 keepalived 的 状 
太 


AN 


[root@kube32 ~]# systemctl status keepalived -1 
e keepalived.service - LVS and VRRP High Availability Monitor 
Loaded: loaded (/usr/lib/systemd/system/keepalived.service; e 
nabled; vendor preset: disabled) 
Active: active (running) since Thu 2018-02-01 10:24:51 CST; 1 
months 16 days ago 
Main PID: 13448 (keepalived) 
Memory: 6.0M 
CGroup: /system.slice/keepalived.service 
13448 /usr/sbin/keepalived -D 
l-13449 /usr/sbin/keepalived -D 
L—13450 /usr/sbin/keepalived -D 


Mar 20 04:51:15 kube32 Keepalived vrrp[13450]: VRRP Instance(VI- 
kube-master) Dropping received VRRP packet... 

**Mar 20 04:51:18 kube32 Keepalived vrrp[13450]: (VI-kube-master) 
: ip address associated with VRID 51 not present in MASTER adver 

t : 10.86.13.36 

Mar 20 04:51:18 kube32 Keepalived vrrp[13450]: bogus VRRP packet 
received on ethO !!!** 


B n——'ÁÀá T 


然后 通过 systemctl status haproxy -| 看 haproxy 的 状态 


[root@kube32 ~]# systemctl status haproxy -了 
e haproxy.service - HAProxy Load Balancer 
Loaded: loaded (/usr/lib/systemd/system/haproxy.service; enab 
led; vendor preset: disabled) 
Active: active (running) since Thu 2018-02-01 10:33:22 CST; 1 
months 16 days ago 
Main PID: 15116 (haproxy-systemd) 
Memory: 3.2M 
CGroup: /system.slice/haproxy.service 
15116 /usr/sbin/haproxy-systemd-wrapper -f /etc/hap 
roxy/haproxy.cfg -p /run/haproxy.pid 
15117 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg 
-p /run/haproxy.pid -Ds 
L15118 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg 
-p /run/haproxy.pid -Ds 


这 个 时 候 通过 kubectl version 命 令 ， 可 以 获取 到 kubectl 的 服务 器 信息 。 


[root@kube32 ~]# kubectl version 

**Client Version: version.Info{Major:"1", Minor:"9", GitVersion: 
"v1.9.1", GitCommit:"3a1c9449a956b6026f075fa3134ff92f7d55f812", 
GitTreeState:"clean", BuildDate:"2018-01-03T22:31:01Z", GoVersio 
n:"go1.9.2", Compiler:"gc", Platform:"linux/amd64") 

Server Version: version.Info{Major:"1", Minor:"9", GitVersion:"v 
1.9.1", GitCommit:"3a1c9449a956b6026f075fa3134ff92f7d55f812", Gi 
tTreeState:"clean", BuildDate:"2018-01-03T22:18:41Z", GoVersion: 
"go1.9.2", Compiler:"gc", Platform:"linux/amd64")** 


这 个 时 候 说 明 你 的 keepalived 和 haproxy 都 是 成 功 的 。 这 个 时 候 你 可 以 依次 将 你 其 他 
Master 节 点 的 keepalived 和 haproxy 启 动 。 此 时 ， 你 通过 ip a s 命 令 去 查看 其 中 一 
Master ( 非 主 Master) 的 时 候 ， 你 看 不 到 VIP， 这 个 是 正常 的 ， 因 为 VIP 永远 只 在 主 
Master 节 点 上 ， 只 有 当主 Master 节 点 挂 掉 后 ， 才 会 切换 到 其 他 Master 节 点 上 。 


[root@kube31 ~]# ipa s 
1: lo: <LOOPBACK, UP, LOWER_UP> mtu 65536 qdisc noqueue state UNKN 
OWN qlen 1 
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 
inet 127.0.0.1/8 scope host lo 
valid_lft forever preferred_lft forever 
inet6 ::1/128 scope host 
valid_lft forever preferred_lft forever 
2: eth0: «BROADCAST, MULTICAST, UP, LOWER UP» mtu 1500 qdisc mq sta 
te UP qlen 1000 
link/ether 00:50:56:a9:07:23 brd ff: ff: ff: fF: FF: FF 
inet 10.86.13.31/23 brd 10.86.13.255 scope global ethO 
valid lft forever preferred lft forever 
inet6 fe80::250:56ff:fea9:723/64 scope link 
valid lft forever preferred lft forever 


在 我 的 实践 过 程 中 ， 通 过 AQ 启动 多 个 Master 节 点 ， 会 导致 主 Master 始 
终 获 取 不 了 VIP， 当 时 的 报错 非常 奇怪 。 sia e ， 主 Master 获 取 VIP 
是 需要 时 间 的 ， 如 果 多 dui cs 时 局 动 ， ey 冲突 。 这 个 不 知道 是 否 算是 
Keepalived 的 Bug。 但 是 最 稳妥 的 方式 还 是 先 启 动 一 台 主 Master， 等 VIP 确定 后 再 局 
动 其 他 Master 比 较 靠 谱 。 


Kubernetes 通 过 Keepalived + Haproxy 实 现 多 个 Master 的 高 可 用 部 署 ， 你 实际 上 可 
以 采用 其 他 方式 ， 如 外 部 的 负载 均衡 方式 。 实 际 上 Kubernetes 的 多 个 Master 是 没有 
主 从 的 ， 都 可 以 提供 一 致 性 服务 。Keepalived + Haproxy 实 际 上 就 是 提供 了 一 个 简 

单 的 负载 均衡 方式 。 
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服务 滚动 升级 


当 有 镜像 发 布 新 版 本 ， 新 版 本 服务 上 线 时 如 何 实 现 服务 的 滚动 和 平滑 升级 ? 


如 果 你 使 用 ReplicationController 创 建 的 pod 可 以 使 用 kubect1 
rollingupdate 命令 滚动 升级 ， 如 果 使 用 的 是 Deployment 创 建 的 Pod 可 以 直接 修 
改 yaml| 文 件 后 执行 kubectl apply 即 可 。 


Deployment 已 经 内 置 了 RollingUpdate strategy， 因 此 不 用 再 调用 kubect1 
rollingupdate 命令 ， 升 级 的 过 程 是 先 创建 新 版 的 pod 将 流量 导入 到 新 pod 上 后 销 
St JR 3k AY € AY pod 。 


Rolling Update 适 用 于 Deployment ^ Replication Controller ， 官 方 推荐 使 
用 Deployment 而 不 再 使 用 Replication Controller ° 


使 用 ReplicationController 时 的 滚动 升级 请 参考 官网 说 
8] : https://kubernetes.io/docs/tasks/run-application/rolling-update-replication- 
controller 


ReplicationController 与 Deployment 的 关系 


ReplicationController 和 Deployment 的 RollingUpdate 命 令 有 些 不 同 ， 但 是 实现 的 机 
制 是 一 样 的 ， 关 于 这 两 个 kind 的 关系 我 引用 了 ReplicationController 与 Deployment 
的 区 别 中 的 部 分 内 容 如 下 ， 详 细 区 别 请 查看 原文 。 


ReplicationController 


Replication Controller 为 Kubernetes 的 一 个 核心 内 容 ， 应 用 托管 到 Kubernetes 之 
后 ， 需 要 保证 应 用 能 够 持续 的 运行 ，Replication Controller 就 是 这 个 保证 的 key， 主 
要 的 功能 如 下 


e 确保 pod 数 量 : 它 会 确保 Kubernetes 中 有 指定 数量 的 Pod 在 运行 。 如 果 少 于 指 
定数 量 的 pod，Replication Controller 会 创建 新 的 ， 反 之 则 会 删除 掉 多 余 的 以 保 
证 Pod 数 量 不 变 。 

e 确保 pod 健 康 : 当 pod 不 健康 ， 运 行 出 错 或 者 无 法 提供 服务 时 ，Replication 
Controller 也 会 杀 死 不 健康 的 pod， 重 新 创建 新 的 。 


e 弹性 伸缩 : 在 业务 高 峰 或 者 低 峰 期 的 时 候 ， 可 以 通过 Replication Controller 
态 的 调整 pod 的 数量 来 提高 资源 的 利用 率 。 同 时 ， 配 置 相 应 的 监控 功能 
(Hroizontal Pod Autoscaler) ， 会 定时 自动 从 监控 平台 ee 
Controller 关 联 pod 的 整体 资源 使 用 情况 ， 做 到 自 
e 滚动 升级 : 滚动 升级 为 一 种 平滑 的 升级 方式 ， 通 过 逐步 替换 的 策略 ， 保 证 整体 
系统 的 稳定 ， 在 初始 化 升级 的 时 候 就 可 以 及 时 发 现 和 解决 问题 ， 避 免 问 题 不 断 
扩大 。 


Deployment 


Deployment 同 样 为 Kubernetes 的 一 个 核心 内 容 ， 主 要 职责 同样 是 为 了 保证 pod 的 数 
量 和 健康 ，90% 的 功能 与 Replication Controller 完 全 一 样 ， 可 以 看 做 新 一 代 的 
Replication Controller。 但 是 ， 它 又 具备 了 Replication Controller 之 外 的 新 特性 : 


e Replication Controller 全 部 功能 : Deployment 继 承 了 上 面 描述 的 Replication 
Controller 全 部 功能 。 

e 事件 和 状态 查看 : 可 以 查看 Deployment 的 升级 详细 进度 和 状态 。 

e HR: 当 升 级 pod 镜 像 或 者 相关 参数 的 时 候 发 现 问题 ， 可 以 使 用 回 滚 操 作 回 滚 
到 上 一 个 稳定 的 版 本 或 者 指定 的 版 本 。 

e 版 本 记录 : 每 一 次 对 Deployment 的 操作 ， 都 能 保存 下 来 ， 给 予 后 续 可 能 的 回 滚 
使 用 。 

e 暂停 和 启动 : 对 于 每 一 次 升级 ， 都 能 够 随时 暂停 和 启动 。 

e 多 种 升级 方案 : Recreate: 删除 所 有 已 存在 的 pod, 重 新 创建 新 的 ; 
RollingUpdate : 滚动 升级 ， 和 逐步 替换 的 策略 ， 同 时 滚动 升级 时 ， 支 持 更 多 的 附 
加 参数 ， 例 如 设置 最 大 不 可 用 pod 数 量 ， 最 小 升级 间隔 时 间 等 等 。 


创建 测试 镜像 


我 们 来 创建 一 个 特别 简单 的 web 服 务 ， 当 你 访问 网 页 时 ， 将 输出 一 名 版 本 信息 。 通 
区 分 这 名 版 本 信息 输出 我 们 就 可 以 断定 升级 是 否 完 成 。 
所 有 配置 和 代码 见 ../manifests/test/rolling-update-test 目 录 。 


Web 服 务 的 代码 main.go 


package main 


import ( 
"Fmt " 
"log" 
"net/http" 
) 


func sayhello(w http.ResponseWwriter, r *http.Request) ( 
fmt.Fprintf(w, "This is version 1.") // 这 个 写 入 到 w 的 是 输出 到 客户 

端的 

j 


func main() (1 
http.HandleFunc("/", sayhello) // 设 置 访问 的 路 由 
log.Println("This is version 1.") 
err := http.ListenAndServe(":9090", nil) // 设 置 监听 的 端口 
if err != nil { 
log.Fatal("ListenAndServe: ", err) 


} 


4 32 Dockerfile 


FROM alpine:3.5 

MAINTAINER Jimmy Song<rootsongjc@gmail.com> 
ADD hellov2 / 

ENTRYPOINT ["/hellov2"] 


注意 修改 添加 的 文件 的 名 称 。 
创建 Makefile 
修改 镜像 仓库 的 地 址 为 你 自己 的 私有 镜像 仓库 地 址 。 


修改 Makefile 中 的 TAG 为 新 的 版 本 号 。 


all: build push clean 
.PHONY: build push clean 


TAG = vi 
# Build for linux amd64 
build: 


GOOS-linux GOARCH=amd64 go build -o hello${TAG} main.go 
docker build -t harbor-001.jimmysong.io/library/hello:${TAG} 


# Push to tenxcloud 
push: 
docker push harbor-001.jimmysong.io/library/hello:${TAG} 


# Clean 
clean: 
rm -f helloS{TAG} 


编译 
make all 


分 别 修改 main.go 中 的 输出 语句 、Dockerfile 中 的 文件 名 称 和 Makefile 中 的 TAG， 创 
建 两 个 版 本 的 镜像 。 


测试 
我 们 使 用 Deployment 部 署 服务 来 测试 。 


配置 文件 rolling-update-test.yaml 


apiVersion: extensions/vibeta1 
kind: Deployment 
metadata: 
name: rolling-update-test 
spec: 
replicas: 3 
template: 
metadata: 

labels: 
app: rolling-update-test 

spec: 

containers: 

- name: rolling-update-test 
image: harbor-001.jimmysong.io/library/hello:vi 
ports: 

- containerPort: 9090 
apiVersion: vi 
kind: Service 


metadata: 
name: rolling-update-test 
labels: 
app: rolling-update-test 
spec: 
ports: 
- port: 9090 
protocol: TCP 
name: http 
selector: 


app: rolling-update-test 


3f X service 

kubectl create -f rolling-update-test.yaml 
修改 traefik ingress c £ 
在 ingress.yaml 文件 中 增加 新 service 的 配置 。 


- host: rolling-update-test.traefik.io 


http: 
paths: 
- path: / 
backend: 


serviceName: rolling-update-test 
servicePort: 9090 


修改 本 地 的 host 配 置 ， 增 加 一 条 配置 : 
172.20.0.119 rolling-update-test.traefik.io 

注意 : 172.20.0.119 是 我 们 之 前 使 用 keepalived 创 建 的 VIP ° 

打开 浏览 器 访问 http://rolling-update-test.traefik.io 将 会 看 到 以 下 输出 : 
This is version 1. 


滚动 升级 


只 需要 将 rolling-update-test.yaml 文件 中 的 image 改 成 新 版 本 的 镜像 名 ， 
然后 执行 : 


kubectl apply -f rolling-update-test.yaml 


也 可 以 参考 Kubernetes Deployment Concept 中 的 方法 ， 直 接 设 置 新 的 镜像 。 


kubectl set image deployment/rolling-update-test rolling-update- 
test-harbor-001.jimmysong.io/library/hello:v2 


或 者 使 用 kubectl edit deployment/rolling-update-test 修改 镜像 名 称 后 保 
po 


使 用 以 下 命令 查看 升级 进度 : 


kubectl rollout status deployment/rolling-update-test 


升级 完成 后 在 浏览 器 中 刷新 http:Wrolling-update-test.traefik.io 将 会 看 到 以 下 输出 : 


This is version 2. 
说 明 滚 动 升 级 成 功 。 


使 用 ReplicationController 创 建 的 Pod 如 何 
RollingUpdate 


以 上 讲解 使 用 Deployment 创 建 的 Pod 的 RollingUpdate 方 式 ， 那 么 如 果 使 用 传统 的 
ReplicationController 创 建 的 Pod 如 何 Update 呢 ? 


举 个 例子 : 


$ kubectl -n spark-cluster rolling-update zeppelin-controller -- 
image harbor -001.jimmysong.io/library/zeppelin:0.7.1 

Created zeppelin-controller -99be89dbbe5cd5b8d6feab8f57a04a8b 
Scaling up zeppelin-controller -99be89dbbe5cd5b8d6feab8f57a04a8b 
from 0 to 1, scaling down zeppelin-controller from 1 to 0 (keep 
1 pods available, don't exceed 2 pods) 

Scaling zeppelin-controller -99be89dbbe5cd5b8d6feab8f57a04a8b up 
to 1 

Scaling zeppelin-controller down to 0 

Update succeeded. Deleting old controller: zeppelin-controller 
Renaming zeppelin-controller-99be89dbbe5cd5b8d6feab8f57a04a8b to 
zeppelin-controller 

replicationcontroller "zeppelin-controller" rolling updated 


只 需要 指定 新 的 镜像 即 可 ， 当 然 你 可 以 配置 RollingUpdate 的 策略 。 


考 


e Rolling update 机 制 解 析 
e Running a Stateless Application Using a Deployment 


Simple Rolling Update 
e 4% fl kubernetes 4 deployment3t £T RollingUpdate 


Copyright © jimmysong.io 2017-2018 all right reserved > powered by 
GitbookUpdated at 2018-05-09 14:15:47 


应 用 日 志 收 集 


在 进行 日 志 收 集 的 过 程 中 ， 我 们 首先 想到 的 是 使 用 Logstash， 因 为 它 是 ELK stack 
中 的 重要 成 员 ， 但 是 在 测试 过 程 中 发 现 ，Logstash 是 基于 JDK 的 ， 在 没有 产生 日 志 
的 情况 单纯 启动 Logstash 就 大 概要 消耗 500M 内 存 ， 在 每 个 Pod 中 都 启动 一 个 日 志 收 
集 组 件 的 情况 下 ， 使 用 logstash 有 点 浪费 系统 资源 ， 经 人 推荐 我 们 选择 使 

用 Filebeat 替 代 ， 经 测试 单独 启动 Filebeat 容 器 大 约会 消耗 12M 内 存 ， 比 起 logstash 
相当 轻 量 级 。 


方案 选择 


Kubernetes 官 方 提供 了 EFK 的 日 志 收 集 解决 方案 ， 但 是 这 种 方案 并 不 适合 所 有 的 业 
务 场景 ， 它 本 身 就 有 一 些 局 限 性 ， 例 如 : 


e 所 有 日 志 都 必须 是 out 前 人 台 输 出 ， 丨 实业 务 场 景 中 无 法 保证 所 有 日 志 都 在 前 人 台 输 
出 

e 只 能 有 一 个 日 志 输 出 文件 ， 而 申 实 业务 场景 中 往往 有 多 个 日 志 输 出 文件 

e Fluentd 并 不 是 常用 的 日 志 收 集 工具 ， 我 们 更 习惯 用 logstash， 现 使 用 filebeat 替 
代 

e 我 们 已 经 有 自己 的 ELK 集 群 且 有 专人 维护 ， 没 有 必要 再 在 kubernetes 上 做 一 个 
日 志 收 集 服务 


基于 以 上 几 个 原因 ， 我 们 决定 使 用 自己 的 ELK 集 群 。 


Kubernetes 集 群 中 的 日 志 收 集 解 决 方案 


方案 优点 
部 署 方便 ，kubernetes 的 
每 个 app 的 镜像 中 都 集 yaml 文 件 无 须 特别 配置 ， 


成 日 志 收 集 组 件 


单独 创建 一 个 日 志 
ea ses 容器 
运行 在 同 ee 


Seo 


可 以 为 每 个 app 自 定义 日 
志 收 集 配置 


低 耦 合 ， 扩 展 性 强 ， 方 便 
维护 和 升级 


将 所 有 的 Pod 的 日 志 都 


挂 载 到 宿主 机 上 ， 每 
台 主 机 上 单独 起 一 个 


日 志 收 集 Pod 


综合 以 上 优 缺 点 ， 我 们 选择 


方案 在 扩展 性 、 个 性 化 、 部 署 和 后 期 维护 方面 都 


CARS BERE Ë 
理 起 来 最 方便 


使 用 方案 二 


缺点 


强 耦 合 ， 不 方便 应 
用 和 日 志 收 集 组 件 
升级 和 维护 且 会 导 
致 镜像 过 大 


需要 对 Kubernetes 
的 yam| 文 件 进行 单 
jh he o x i 


规则 ， 目 录 和 输出 
AX 


EE 做 到 均衡 ， 因 此 选择 该 方案 


o 
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filebeat-test.yaml 


Log 





1 apiVersion: extensions/vlbetal 

2 kind: Deployment . 
3 m metadata; Collection 
6 spec: 

7 replicas: 3 

8 template: 

9 m metadata: = 

12 spec: 

13 containers: 

14 - image: filebeat:5.4.0~ 

21 - image: docker-test:Build 8- 


volumes: 
— name: app-logs 
emptyDir: {} 
- name: filebeat-config 
configMap: 
name: filebeat-config 


Define 
Bison 


apiVersion: v1 
kind: ConfigMap 
9 metadata: ~ 
data: 
filebeat.yml: | 
filebeat. prospectors: 
- input type: log 
paths: 
= "/log/*" 
- "/log/usermange/common/*" 
output.elasticsearch: 
hosts: ["172.23.5.255:9200"] 
username: "elastic" 
password: "changeme" 
index: "filebeat-test" 

































Wacth 





| 


Doc: filebeat-docker-test/log/AVzs1 QzKdPYTkmBgkats 


June 28th 2017, 11:53:19.425 
AVzsiQzKdPYTkmBgkats 
filebeat-docker-test 

1 

log 

fi lebeat-test-2365467882-4zwx8 
fi lebeat-test-2365467882-4zwx8 
5.4.0 

log 


2017-06-02 15:14:48.592 [net.sf.ehcache.cacheManager@614a616] INFO net.sf.ehcache.util.UpdateChecker-New update(s) found: 2.6.5 [http://www.terracotta.org/confluenc 
e/display/release/Release+Notes+Ehcache+Core+2.6]. Please check http://ehcache.org for the latest version. 


272 
/109/2017 06. 02. stderrout.log 


log 


© Jimmy Song https://github.com/rootsongjc/kubernetes-handbook 





图 片 - filebeat 日 志 收 集 架 构图 


我 们 创建 了 自己 的 filebeat 镜 像 。 创 建 过 程 和 使 用 方式 见 
https://github.com/rootsongjc/docker-images 


镜像 地 址 : 


i] ix 


index.tenxcloud.com/jimmy/filebeat:5.4.0 


我 们 部 署 一 个 应 用 filebeat 来 收集 日 志 的 功能 测试 。 


创建 应 用 yaml 文 件 filebeat-test.yaml ° 


apiVersion: 


extensions/vibetai 


kind: Deployment 


metadata: 








name: filebeat-test 
namespace: default 
spec: 
replicas: 3 
template: 
metadata: 

labels: 
k8s-app: filebeat-test 

spec: 

containers: 

- image: harbor-001.jimmysong.io/library/filebeat:5.4.0 
name: filebeat 
volumeMounts: 

- name: app-logs 
mountPath: /log 

- name: filebeat-config 
mountPath: /etc/filebeat/ 

- image: harbor-001.jimmysong.io/library/analytics-docker- 

test:Build 8 
name : app 
ports: 
- containerPort: 80 
volumeMounts: 
- name: app-logs 
mountPath: /usr/local/TalkingData/logs 
volumes: 

- name: app-logs 
emptyDir: {} 

- name: filebeat-config 
configMap: 

name: filebeat-config 
apiVersion: v1 
kind: Service 


metadata: 
name: filebeat-test 
labels: 
app: filebeat-test 
spec: 
ports: 
- port: 80 
protocol: TCP 
name: http 
selector: 


run: filebeat-test 
apiVersion: v1 
kind: ConfigMap 
metadata: 
name: filebeat-config 
data: 
filebeat.yml: | 
filebeat.prospectors: 


- input_type: log 
paths: 
= "/log/*" 
- "/log/usermange/common/*" 
output.elasticsearch: 
hosts: ["172.23.5.255:9208" | 
username: "elastic" 
password: "changeme" 
index: "filebeat-docker-test" 


说 明 


该 文件 中 包含 了 配置 文件 filebeat 的 配置 文件 的 ConfigMap， 因 此 不 需要 再 定义 环境 


里 o 
当然 你 也 可 以 不 同 ConfigMap， 通 过 传统 的 传递 环境 变量 的 方式 来 配置 filebeat 。 


例如 对 filebeat 的 容器 进行 如 下 配置 : 


containers: 

- image: harbor-001.jimmysong.io/library/filebeat:5.4.0 
name: filebeat 
volumeMounts: 

- name: app-logs 
mountPath: /log 

env: 

- name: PATHS 

value: "/log/*" 

name: ES SERVER 

value: 172.23.5.255:9200 

- name: INDEX 
value: logstash-docker 

- name: INPUT TYPE 
value: log 


目前 使 用 这 种 方式 会 有 个 问题 ， 及 时 PATHS 只 能 传递 单个 目录 ， 如 果 想 传递 多 个 
目录 需要 修改 filebeat 镜 像 的 docker-entrypoint.sh 脚本 ， 对 该 环境 变量 进行 解 
析 增 加 filebeat.yml 文 件 中 的 PATHS 列 表 。 
推荐 使 用 ConfigMap， 这 样 flebeat 的 配置 就 能 够 更 灵活 。 
注意 事项 

e 将 app 的 /usr/local/TalkingData/logs 目录 挂 载 到 filebeat 的 /log 目录 

"ER 
e 该 文件 可 以 在 manifests/test/filebeat-test.yaml 找到 。 


。 我 使 用 了 自己 的 私有 镜像 仓库 ， 测 试 时 请 换 成 自己 的 应 用 镜像 。 
e Filebeat 的 环境 变量 的 值 配 置 请 参考 https://github.com/rootsongjc/docker- 
images 


创建 应 用 


部 署 Deployment 


kubectl create -f filebeat-test.yaml 


查看 http://172.23.5.255:9200/ cat/indices 将 可 以 看 到 列表 有 这 样 的 
indices : 


green open filebeat-docker-test 7XPEwEbUQRirk80DX36gA 
A51 2151 0 1.6mb 841.8kb 


访问 Kibana 的 web 页 面 ， 查 看 filebeat-2017.05.17 的 索引 ， 可 以 看 到 fllebeat 收 
集 到 了 app 日 志 。 
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图 片 - Kibana 页 面 





点 开 每 个 日 志 条 目 ， 可 以 看 到 以 下 详细 字段 : 





Doc: filebeat-docker-test/log/AVzs1 QzKdPYTkmBgkats 


Table JSON 


Gtimestamp June 28th 2017, 11:53:19.425 


-id AVzslQzKdPYTkmBgkats 
-score 1 
type log 


beat.hostname filebeat-test-2365467882-4zwx8 


ooraorto PN 


beat.name fi lebeat-test-2365467882-4zwx8 
beat.version 5.4.0 


input type log 


message 2017-06-02 15:14:48.592 [net.sf.ehcache.CacheManager(614a616] INFO net.sf.ehcache.util.UpdateChecker-New update(s) found: 2.6.5 [http://www.terracotta.org/confluenc 
e/display/release/Release+Notes+Ehcache+Core+2.6]. Please check http://ehcache.org for the latest version. 

offset 272 

type log 





图 片 - fijlebeat 收 集 的 日 志 详 细 信 息 


e index 值 即 我 们 在 YAML 文 件 的 configMap 中 配置 的 index 值 
e beat.hostname 和 beat.name 即 pod 的 名 称 
e Source 表 示 filebeat 容 器 中 的 日 志 目 录 


我 们 可 以 通过 人 为 得 使 index = service name ， 这 样 就 可 以 方便 的 收集 和 查看 
每 个 service 的 日 志 。 
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置 最 佳 实践 


本 文档 旨 在 汇总 和 强调 用 户 指南 、 快 速 开始 文档 和 示例 中 的 最 佳 实践 。 该 文档 会 很 
活跃 并 持续 更 新 中 。 如 果 你 觉得 很 有 用 的 最 佳 实践 但 是 本 文档 中 没有 包含 ， 欢 迎 给 
我 们 提 Pull Request 。 


通用 配置 建议 


e 定义 配置 文件 的 时 候 ， 指 定 最 新 的 稳定 API 版 本 (目前 是 V1) 。 

e 在 配置 文件 push 到 集群 之 前 应 该 保存 在 版 本 控制 系统 中 。 这 样 当 需要 的 时 候 能 
够 快速 回 滚 ， 必 要 的 时 候 也 可 以 快速 的 创建 集群 。 

e 使 用 YAML 格 式 而 不 是 JSON 格 式 的 配置 文件 。 在 大 多 数 场景 下 它们 都 可 以 作为 
数据 交换 格式 ， 但 是 YAML 格 式 比 起 JSON 更 易 读 和 配置 

e 尽量 将 相关 的 对 象 放 在 同一 个 配置 文件 里 。 Re RARER ES 
4 % guestbook-all-in-one. Lee 配置 (注意 ， 尽 管 你 可 以 在 使 
gy cecal 命令 时 指定 配置 文件 目录 ， 你 也 可 以 在 配置 文件 目录 下 执 

pose 

e 为 了 简化 和 最 小 化 配置 ， 也 为 了 防止 错误 发 生 ， 不 要 指定 不 必要 的 默认 配置 。 
例如 ， 省 略 掉 ReplicationController 的 selector 和 |abel， 如 果 你 希望 它们 
跟 podTemplate 中 的 label 一 样 的 话 ， 因 为 那些 配置 默认 是 podTemplate 的 
label 产 生 的 。 更 多 信息 请 查看 guestbook app 的 yaml 文 件 和 examples 。 

e. 将 资源 对 象 的 描述 放 在 一 个 annotation 中 可 以 更 好 的 内 省 。 





裸 的 Pods vs Replication Controllers 和 Jobs 


e 如 果 有 其 他 方式 替代 “ 裸 的 * pod〈 如 没有 绑 定 到 replication controller 上 的 
pod) ， 那 么 就 使 用 其 他 选择 。 在 node 节 点 出 现 故 障 时 ， 裸 奔 的 pod 不 会 被 重 
新 调度 。Replication Controller 总 是 会 重新 创建 pod， 除 了 明确 指定 
了 restartPolicy: Never 的 场景 。Job 也 许 是 比较 合适 的 选择 。 


Services 


e 通常 最 好 在 创建 相关 的 replication controllers2 3$ A4l service ， 你 也 可 以 在 


$] Replication Controller 49 H 4% #48 Æ replicaž © (默认 是 1) » &] service 
后 ， 在 通过 Replication Controller 来 扩容 。 这 样 可 以 在 扩容 很 多 个 replica 之 前 
先 确认 pod 是 正常 的 。 

e 除非 十 分 必要 的 情况 下 (如 运行 一 个 node daemon) ， 不 要 使 
hostPort (用 来 指定 暴露 在 主机 上 的 端口 号 ) 。 当 你 给 Pod 绑 定 了 一 

个 hostPort ， 该 pod 可 被 调度 到 的 主机 的 受 限 了 ， 因 为 端口 冲突 。 如 果 是 为 

oan 目的 来 通过 端口 访问 的 话 ， 你 可 以 使 用 kubectl proxy and apiserver 
proxy 或 者 kubectl port-forward。 你 可 使 用 Service 来 对 外 暴露 服务 。 如 果 你 
确实 需要 将 pod 的 端口 暴露 到 主机 上 ， 考 虑 使 用 NodePort service 。 

e JR hostPort 一 样 的 原因 ， 训 免 使 用 hostNetwork 。 

e 如 果 你 不 需要 kube-proxy 的 负载 均衡 的 话 ， 可 以 考虑 使 用 使 用 headless 
services ° 


使 用 Label 


e X 3 labels 来 指定 应 用 或 Deployment 的 semantic attributes 。 例 如 ， 不 是 将 
label 附 加 到 一 组 pod 来 显 式 表示 某 些 服务 〈 例 如 ， service:myservice ) ， 
或 者 显 式 地 表示 管理 pod 的 replication controller (44 
如 ， controller:mycontroller ) ， 附 加 label 应 该 是 标示 语义 属性 的 标 

签 ， 例 如 ee ee pe o 这 

将 允许 您 选 

eh “ 测 | 斌 "阶段 组 件 。 关 此 方法 的 示例 ， 请 参 

阅 guestbook 应 用 程序 。 


yg. [11 
^ 











可 以 通过 简单 地 从 其 service 的 选择 器 中 省 略 特定 于 发 行 版 本 的 标签 ， 而 不 是 更 
新 服务 的 选择 器 来 完全 匹配 replication controller 的 选择 器 ， 来 实现 跨越 多 个 部 
署 的 服务 ， 例 如 滚动 更 新 。 


e 为 了 滚动 升级 的 方便 ， 在 Replication Controller 的 名 字 中 包含 版 本 信息 ， 例 如 
作为 名 字 的 后 级 。 设 置 一 个 version 标签 页 是 很 有 用 的 。 滚 动 更 新 创建 
3t 4 controller n 75 z& 17 AILA $4 controller » AX > version 2 iE 73 83 
controller 名 字 就 可 能 带 来 问题 。 查 看 Rolling Update Replication Controller c 
档 获 取 更 多 关于 滚动 升级 命令 的 信息 。 


注意 Deployment 对 象 不 需要 再 管理 replication controller 的 版 本 名 » 
Deployment 中 描述 了 对 象 的 X ni 态 ， 如 果 对 spec 的 更 改 被 应 用 了 话 ， 
Deployment controller 会 以 控制 的 速率 来 更 改 实际 状态 到 期 望 状态 。 


(Deployment A ay extensions API Group 的 一 部 分 ) 。 


e 利用 label 做 调试 。 因 为 Kubernetes replication controller 和 service 使 用 label 来 
匹配 pods， 这 人 允许 你 通过 移 除 pod 中 的 label 的 方式 将 其 从 一 个 controller 或 者 
service 中 移 除 ， 原 来 的 controller 会 创建 一 个 新 的 pod 来 取代 移 除 的 pod。 这 是 
一 个 很 有 用 的 方式 ， 帮 你 在 一 个 隔离 的 环境 中 调试 之 前 的 “活着 的 ” pod。 查 看 

kubectl label 命令 。 


容器 镜像 


e 默认 容器 镜像 拉 取 策略 IfNotPresent , 当 本 地 已 存在 该 镜像 的 时 候 
Kubelet 不 会 再 从 镜像 仓库 拉 取 。 如 果 你 希望 总 是 从 镜像 仓库 中 拉 取 镜像 的 
话 ， 在 yaml 文 件 中 指定 镜像 拉 取 策略 为 Always ( imagePullPolicy: 
Always ) 或 者 指定 镜像 的 tag 为 :latest ° 


如 果 你 没有 将 镜像 标签 指定 为 :latest ， 例 如 指定 为 myimage:vi ， 当 该 标 
签 的 镜像 进行 了 更 新 ，kubelet 也 不 会 拉 取 该 镜像 。 你 可 以 在 每 次 镜像 更 新 后 都 
生成 一 个 新 的 tag (例如 myimage:v2 ) ， 在 配置 文件 中 明确 指定 该 版 本 。 


注意 : 在 生产 环境 下 部 署 容 器 应 该 尽量 避免 使 用 :latest 标签 ， 因 为 这 样 很 
难 追 溯 到 底 运 行 的 是 哪个 版 本 的 容 颖 和 回 滚 。 


使 用 kubectl 


e 尽量 使 用 kubectl create -f «directory» “。kubeclt 会 自动 查找 该 目录 下 
的 所 有 后 组 名 为 .yaml ^ .yml 和 ,json 文件 并 将 它们 传递 给 create 命 
A o 

e 使 用 kubectl delete 而 不 是 stop. Delete 是 stop 的 超 集 ， stop 
CARAM ° 

e 使 用 kubectl bulk 操作 (通过 文件 或 者 label) 来 get 和 delete。 查 看 label 
selectors 和 using labels effectively ° 

e 使 用 kubectl run 和 expose 命令 快速 创建 只 有 单个 容器 的 
Deployment。 查 看 quick start guide 中 的 示例 。 


e Configuration Best Practices 
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集群 及 应 用 监控 


在 前 面 的 安装 heapster 插 件 章 节 ， 我 们 已 经 谈 到 Kubernetes 本 身 提 供 了 监控 插件 作 
为 集群 和 容器 监控 的 选择 ， 但 是 在 实际 使 用 中 ， 因 为 种 种 原因 ， 再 考虑 到 跟 我 们 自 
身 的 监控 系统 集成 ， 我 们 准备 重新 造 轮子 。 


针对 kubernetes 集 群 和 应 用 的 监控 ， 相 较 于 传统 的 虚拟 机 和 物理 机 的 监控 有 很 多 不 
同 ， 因 此 对 于 传统 监控 需要 有 很 多 改造 的 地 方 ， 需 要 关注 以 下 三 个 方面 : 


e Kubernetes 集 群 本 身 的 监控 ， 主 要 是 kubernetes 的 各 个 组 件 
e kubernetes 集 群 中 Pod 的 监控 ，Pod 的 CPU、 内 存 、 网 络 、 磁 盘 等 监控 
e 集群 内 部 应 用 的 监控 ， 针 对 应 用 本 身 的 监控 


Kubernetes 和 集群 中 的 监控 


Frontend/Backend 
Application (website, mobile app, database, cache...) 


labels Environment (prod, staging, dev...) 


Team 


Monitoring in Kubernetes Version 


applications tracking when they moved 


more components 


heapster 
metrics source 
native containers/cadvisor 


图 片 - Kubernetes 集 群 中 的 监控 


跟 物 理 机 器 和 虚拟 机 的 监控 不 同 ， 在 kubernetes 集 群 中 的 监控 复杂 度 更 高 一 些 ， 
为 多 了 一 个 虚拟 化 层 ， 当 然 这 个 跟 直 接 监控 docker 容 器 又 不 一 样 ，kubernetes 在 
docker 之 上 又 抽象 了 一 层 service 的 概念 。 


集 = BE A 用 Ww 控 


在 kubernetes 中 的 监控 需要 考虑 到 这 几 个 方面 : 


e 应 该 给 Pod 打 上 哪些 label， 这 些 label 将 成 为 监控 的 metrics。 

e 当 应 用 的 Pod 漂 移 了 之 后 怎么 办 ? 因为 要 考虑 到 Pod 的 生命 周期 比 庶 拟 机 和 物 
理 机 短 的 多 ， 如 何 持续 监控 应 用 的 状态 ? 

e 更 多 的 监控 项 ，kubernetes 本 身 、 容 器 、 应 用 等 。 

e 监控 指标 的 来 源 ， 是 通 Sas ae 汇聚 还 是 直接 从 每 台 主 机 的 docker 上 


首先 我 们 需要 清楚 使 用 CAdvisor 收 集 的 数据 的 格式 和 字段 信息 。 


当 我 们 通过 cAdvisor 获 取 到 了 容器 的 信息 后 ， 例 如 访 
i] ${NODE_IP}:4194/api/vi.3/docker oa 告 果 中 的 某 个 容器 包含 如 下 
字段 : 


"labels": { 
"annotation.io.kubernetes.container.hash": "f47f0602" 
了 
"annotation.io.kubernetes.container.ports": "[{\"con 


tainerPort\":80, \"protocol\":\"TCP\"}]", 

"annotation.io.kubernetes.container.restartCount": " 
o", 

"annotation.io.kubernetes.container.terminationMessa 
gePath": "/dev/termination-log", 

"annotation.io.kubernetes.container.terminationMessa 
gePolicy": "File", 

"annotation.io.kubernetes.pod.terminationGracePeriod" 

"30", 

"io.kubernetes.container.logpath": "/var/log/pods/d8 
a2e995-3617-11e7-a4b0-ecf4bbe5d414/php-redis 0.1log", 
io.kubernetes.container.name": "php-redis", 
"io.kubernetes.docker.type": "container", 
io.kubernetes.pod.name": "frontend-2337258262-7711z" 


"io.kubernetes.pod.namespace": "default", 
io.kubernetes.pod.uid": "d8a2e995-3617-11e7-a4b0-ec 
f4bbe5d414", 

"jio.kubernetes.sandbox.id": "843a0f018cOcef2ab5451434 
713ea3f409f0debc2101d2264227e814ca0745677" 


ty 


c 


这 些 信息 其 实 都 是 kubernetes 创 建 容 器 时 给 docker container 打 的 Labels ， 使 
用 docker inspect $conainer name 命令 同样 可 以 看 到 上 述 信 息 。 


你 是 否 想 过 这 些 label 跟 容器 的 名 字 有 什么 关系 ? 当 你 在 node 节 点 上 执行 docker 
ps His 容 字 又 对 应 哪个 应 用 的 Pod 呢 ? 


在 kubernetes 代 码 中 pkg/kubelet/dockertools/docker.go 中 的 BuildDockerName 方 法 
定义 了 容器 的 名 称 规范 。 


这 段 容 器 名 称 定义 代码 如 下 


// Creates a name which can be reversed to identify both full po 
d name and container name. 
// This function returns stable name, unique name and a unique i 
d. 
// Although rand.Uint32() is not really unique, but it's enough 
for us because error will 
// only occur when instances of the same container in the same p 
od have the same UID. The 
// chance is really slim. 
func BuildDockerName(dockerName KubeletContainerName, container * 
vi.Container) (string, string, string) { 
containerName :- dockerName.ContainerName + "." + strconv.Fo 
rmatUint(kubecontainer.HashContainerLegacy(container), 16) 
stableName := fmt.Sprintf("9;s 96s 9?6s 96s", 
containerNamePrefix, 
containerName, 
dockerName.PodFullName, 
dockerName.PodUID) 
UID := fmt.Sprintf("%08x", rand.Uint32()) 
return stableName, fmt.Sprintf("%s_%s", stableName, UID), UI 
D 


} 


// Unpacks a container name, returning the pod full name and con 
tainer name we would have used to 
// construct the docker name. If we are unable to parse the name 
, an error is returned. 
func ParseDockerName(name string) (dockerName *KubeletContainerN 
ame, hash uint64, err error) { 
// For some reason docker appears to be appending '/' to nam 
es. 
// If it's there, strip it. 
name = strings.TrimPrefix(name, "/") 
parts := strings.Split(name, "_") 
if len(parts) == || parts[0] != containerNamePrefix { 
err - fmt.Errorf("failed to parse Docker container name 
%q into parts", name) 
return nil, 0, err 
} 


if len(parts) < 6 { 

// We have at least 5 fields. We may have more in the f 
uture. 

// Anything with less fields than this is not something 
we can 

// manage. 

glog.Warningf ("found a container with the %q prefix, but 

too few fields (%d): %q", containerNamePrefix, len(parts), name) 


err = fmt.Errorf("Docker container name %q has less part 
s than expected %v", name, parts) 
return nil, 0, err 


} 
nameParts := strings.Split(parts[1], ".") 
containerName := nameParts[0] 


if len(nameParts) » 1 ( 
hash, err - strconv.ParseUint(nameParts[1], 16, 32) 
if err != nil ( 
glog.Warningf("invalid container hash %q in containe 
r %q", nameParts[1], name) 


j 


podFullName := parts[2] + " " + parts[3] 
podUID :- types.UID(parts[4]) 


return &KubeletContainerName{podFullName, podUID, containerN 
ame}, hash, nil 


j 
国 EE AS 


我 们 可 以 看 到 容器 名 称 中 包含 如 下 几 个 字段 ， 中 间 用 下 划 线 隔 开 ， 至 少 有 6 个 字 
段 ， 未 来 可 能 添加 更 多 字段 。 


下 面 的 是 四 个 基本 字段 。 


containerNamePrefix_containerName_PodFullName_PodUID 


Pf 4 kubernetes È z^ &) & X fj containerNamePrefix4f Æk8s ° 


Kubernetes 启 动 的 docker 容 器 的 容器 名 称 规范 ， 下 面 以 官方 示例 guestbook 为 例 ， 
Deployment 名 为 frontend 中 启动 的 名 为 php-redis 的 docker 容 器 的 副本 书 为 3。 


Deployment frontend 的 配置 如 下 : 


apiVersion: extensions/vibeta1 
kind: Deployment 
metadata: 
name: frontend 
spec: 
template: 
metadata: 
labels: 
app: guestbook 
tier: frontend 
spec: 
containers: 
- name: php-redis 
image: harbor-001.jimmysong.io/library/gb-frontend:v4 
resources: 
requests: 
cpu: 100m 
memory: 100Mi 
env: 
- name: GET HOSTS FROM 
value: dns 
ports: 
- containerPort: 80 


我 们 选取 三 个 实例 中 的 一 个 运行 php-redis 的 docker 容 器 。 


k8s php-redis frontend-2337258262-154p7 default d8a2e2dd-3617-11 
e7-a4b0-ecf4bbe5d414 0 


e containerNamePrefix : k8s 

e containerName : php-redis 

e podFullName : frontend-2337258262-154p7 

e computeHash : 154p7 

e deploymentName : frontend 

e replicaSetName : frontend-2337258262 

e namespace : default 

e podUID : d8a2e2dd-3617-11e7-a4b0-ecf4bbe5d414 


kubernetes 容 器 命名 规则 解析 ， 见 下 图 所 示 。 


k8s php-redis frontend- 2337258262 -154p7_default__ d8a2e2dd-3617-11e7-a4b0-ecf4bbe5d414_0 


ke Í t 


containerNamePrefix 
replicaSetName podFullName namespace podUID restartCount 


containerName 


deploymentName Source http://github.com/rootsongjc/kubernetes-handbook 


使 用 Heapster 进 行 集群 监控 


Heapster 是 kubernetes 官 方 提供 的 监控 方案 ， 我 们 在 前 面 的 章节 中 已 经 讲解 了 如 何 
部 署 和 使 用 heapster， 见 安装 Heapster 括 件 。 


a 根据 Namespace 和 Pod 两 层 来 分 类 ， 实 在 有 些 单薄 ， 我 
们 希望 通过 应 用 的 label 增 加 service 这 一 层 分 类 。 架 构图 如 下 : 


Kubernetes Monitoring Architecture 1 apiVersion: extensions/vibetal 
kind: Deployment 
Kubernetes autedatas 
name: filebeat-test 
namespace: default 
spec: 
replicas: 3 
template: 
metadata: 


e labels: 
Service name - pod label [k8s-app] 11 k8s-app: filebeat-test 


spec: ~ 
apiVersion: v1 
kind: Service 
metadata: 
name: filebeat-test 
labels: 
app: filebeat-test 
a speci- 





Get metrics 4 apiVersion: v1 
) kind: ConfigMap 
metadata: 
name: filebeat-config 





3 & data: ~ 





"container name":"filebeat-test", 

"host. id":"172.168.0.1", 

"hostname":"172.168.0.1", 

"labels": "k8s-app:filebeat-test", 

"namespace id":"7d6c4fd8-2b58-11e7-ad6d-ecf4bbe5d414", 
"namespace name":"default", 

"nodename":"172.168.0.1", 

"pod id":"bee90e2d-4156-116e7-be06-ecf4bbe5d414^", 

"pod name":"filebeat-test-541699390-x12rb", 

"pod namespace":"default", 


"type":;"pod container" Monitoring pod metrics group by 





https://github.com/rootsongjc/kubernetes-handbook 





图 片 - Heapster 架 构图 (改进 版 ) 


集群 及 应 用 监控 
在 不 改变 原 有 架构 的 基础 上 ， 通 过 应 用 的 label 来 区 分 不 同 应 用 的 pod 。 


应 用 监控 


Kubernetes 中 应 用 的 监控 架构 如 图 : 








(3)Sent metrics 


Kubernetes Cluster 





OWL Agent 


(DGet deployment—-pods— 
IP:port and labels 








Get metrics 





图 片 - 应 用 监控 架构 图 


这 种 方式 有 以 下 几 个 要 点 : 


e 访问 kubernetes API 获 取 应 用 Pod 的 IP 和 端口 

e Pod labels 作 为 监控 metric 的 tag 

e 直接 访问 应 用 的 Pod 的 I|P 和 端口 获取 应 用 监控 数据 
e metrics 发 送 到 OWL 中 存储 和 展示 


应 用 拓扑 状态 图 


对 于 复杂 的 应 用 编排 和 依赖 关系 ， 我 们 硕 望 能 够 有 清晰 的 图 标 一 览 应 用 状态 和 拓扑 
关系 ， 因 此 我 们 用 到 了 Weaveworks 开 源 的 scope。 


807 


E 


4 X scope 
我 们 在 kubernetes 集 群 上 使 用 standalone 方 式 安装 ， 详 情 参 考 Installing Weave 
Scope ° 


使 用 scope.yaml 文 件 安 装 scope， 该 服务 安装 在 kube-system namespace F » 


$ kubectl apply -f scope.yaml 


创建 一 个 新 的 Ingress : kube-system.yaml ， 配 置 如 下 : 


apiVersion: extensions/vibeta1 
kind: Ingress 
metadata: 
name: traefik-ingress 
namespace: kube-system 


spec: 
rules: 
- host: scope.weave.io 
http: 
paths: 
- path: / 
backend: 


serviceName: weave-scope-app 
servicePort: 80 


执行 kubectl apply -f kube-system.yaml 后 在 你 的 主机 上 的 /etc/hosts X 
件 中 添加 一 条 记录 : 


172.20.0.119 scope.weave.io 


+ 


在 浏览 器 中 访问 scope.weave.io 就 可 以 访问 到 Scope 了 ， 详 见 边缘 节点 配置 。 


zi 


% weavescope Q SEARCH PROCESSES CONTAINERS PODS HosTS MGRAPH | mB TABLE 
BY NAME ser: 





NS NAME WEAVE NET — Menor 
BY IMAGE 
SERVICES 
istio-ingress filebeat-test frontend glusterfs-cluster grafana 
3 pods 1 pod 
Q o k 
productpage istio-egress istio-manager istio-mixer kubernetes 
1 pod 1 pod 1 pod 1 pod 
© i Q Q 
reviews details prometheus redis-master redis-slave servicegraph 
3 pods 1 pod 1 pod 1 pod 2 pods 1 pod 
Q e t) : ° 
ratings zipkin spark-master spark-ui-proxy zeppelin 
1 pod 1 pod 1 pod 1 pod 1 pod 
{ODES (10 FILTERED) 
‘Show Unmanaged Hide Unmanaged 
"default § —kube-system spark-cluster li Namespace 


VERSION 1.5.1 ON Weave-scope-app-2671460860-Smp4x PLUGINS n/a B © O 3 


图 片 - 应 用 拓扑 图 


| 


如 上 图 所 示 ，scope 可 以 监控 kubernetes 集 群 中 的 一 系列 资源 的 状态 、 资 源 使 用 情 


况 、 应 用 拓扑 、scale、 还 可 以 直接 通过 浏览 器 进入 容器 内 部 调试 等 。 


参考 
e Monitoring in the Kubernetes Era 
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DET & lh] Bay wR 


这 ie 上 是 数据 持久 化 问题 ， 对 于 有 些 应 用 依赖 持久 化 数据 ， 比 如 应 用 自身 产生 的 
志 需 要 持久 化 存储 的 情况 ， 需 要 保证 容器 里 的 数据 不 丢失 ， 在 Pod 挂 掉 后 ， 其 他 
eh 文 此 数据， 因此 我 们 需要 将 数据 持久 化 存储 起 来 。 


数据 沙盘 问题 解决 方案 


下 面 以 一 个 应 用 的 日 志 收 集 为 例 ， 该 日 志 需 要 持久 化 收集 到 ElasticSearch 集 群 中 ， 
如 果 不 考虑 数据 丢失 的 情形 ， 可 以 直接 使 用 前 面 提 到 的 应 用 日 志 收 集 一 节 中 的 方 
法 ， 但 考虑 到 Pod 挂 掉 时 logstash ( Xfilebeat) 并 没有 收集 完 该 pod 内 日 志 的 情形 ， 
我 们 想到 了 如 下 这 种 解决 方案 ， 示 意图 如 下 : 


Node1 Node2 Node3 
label log-reserve=true label log-reserve=true label log-reserve=true 





— 


| Logstash | 








1. 首先 需要 给 数据 落 瘟 的 应 用 划分 node， 即 这 些 应 用 只 调用 到 若干 台 主 机 上 

2. 给 这 若干 人 台 主 机 增加 label 

3. 使 用 deamonset 方式 在 这 若干 台 主 机 上 局 动 logstash 的 Pod (使 用 
nodeSelector 来 限定 在 这 几 台 主机 上 ， 我 们 在 边缘 节点 尼 动 的 treafik 也 是 
这 种 模式 ) 


4. 将 应 用 的 数据 通过 volume 挂 载 到 宿主 机 上 
5. Logstash (或 者 filebeat) 收集 宿主 机 上 的 数据 ， 数 据 持久 化 不 会 丢失 


Side-effect 


1. 首先 kubernetes 本 身 就 提供 了 数据 持久 化 的 解决 方案 statefulset， 不 过 需要 用 
到 公有 云 的 存储 货 其 他 分 布 式 存储 ， 这 一 点 在 我 们 的 私有 云 环境 里 被 否定 了 。 

2. 需要 管理 主机 的 label， 增 加 运 维 复 杂 度 ， 但 是 具体 问题 具体 对 待 

3. 必须 保证 应 用 启动 顺序 ， 需 要 先 启动 logstash 

4. 为 主机 打 label 使 用 nodeSelector 的 方式 限制 了 资源 调度 的 范围 
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管理 容器 的 计算 资源 


当 您 定义 Pod 的 时 候 可 以 选择 为 每 个 容器 指定 需要 的 CPU FAG (RAM) 大 小 。 
当 为 容器 指定 了 资源 请 求 后 ， 调 度 器 就 能 够 更 好 的 判断 出 将 容器 调度 到 哪个 节点 
上 。 如 果 您 还 为 容器 指定 了 资源 限制 ， 节 点 上 的 资源 就 可 以 按照 指定 的 方式 做 竞 
争 。 关 于 资源 请 求 和 限制 的 不 同 点 和 更 多 资料 请 参考 Resource QoS e 


资源 类 型 
CPU 和 memory 都 是 资源 类 型 。 资 源 类 型 具有 基本 单位 。CPU 的 单位 是 core * 
memory 的 单位 是 byte 。 


CPU 和 内 存 统称 为 计算 资源 ， 也 可 以 称 为 资源 。 计 算 资 源 的 数量 是 可 以 被 请 求 、 分 
配 和 消耗 的 可 测量 的 。 它 们 与 AP| 资源 不 同 。API 资源 (如 Pod 和 Service) 是 
可 通过 Kubernetes API server 读 取 和 修改 的 对 象 。 


Pod 和 容器 的 资源 请 求 和 限制 


Pod 中 的 每 个 容器 都 可 以 指定 以 下 的 一 个 或 者 多 个 值 : 


e spec.containers[].resources.limits.cpu 
e spec.containers[].resources.limits.memory 
e spec.containers[].resources.requests.cpu 


e spec.containers[].resources.requests.memory 


尽管 只 能 在 个 别 容器 上 指定 请 求 和 限制 ， 但 是 我 们 可 以 方便 地 计算 出 Pod 资源 请 求 
和 限制 。 特 定 资 源 类 型 的 Pod 资源 请 求 /限制 是 Pod 中 每 个 容器 的 该 类 型 的 资源 请 
求 /限制 的 总 和 。 


CPU 的 含义 
CPU 资源 的 限制 和 请 求 以 cpu 为 单位 。 
Kubernetes 中 的 一 个 cpu 等 于 : 


e 1 AWS vCPU 


e 1 GCP Core 
e 1 Azure vCore 
e 1 Hyperthread 在 带 有 超 线程 的 裸 机 Intel 处 理 器 上 


允许 浮 点 数 请 求 。 具 有 spec.containers[].resources.requests.cpu 为 0.5 
的 容器 保证 了 一 半 CPU 要 求 1 CPU 的 一 半 。 表 达 式 0.1 等 价 于 表达 式 

100m ， 可 以 看 作 “100 millicpu”。 有 些 人 说 成 是 “一 百 毫 cpu”， 其 实说 的 是 同样 的 
事情 。 具 有 小 数 点 (如 0.1 ) 的 请 求 由 API 转换 为 100m ， 精 度 不 超过 1m © 

因此 ， 可 能 会 优先 选择 100m 的 形式 。 


CPU 总 是 要 用 绝对 数量 ， 不 可 以 使 用 相对 数量 ; 0.1 的 CPU 在 单 核 、 双 核 、48 核 
的 机 器 中 的 意义 是 一 样 的 。 


内 存 的 含义 


内 存 的 限制 和 请 求 以 字 节 为 单位 。 您 可 以 使 用 以 下 后 级 之 一 作为 平均 整数 或 定点 整 
数 表示 内 存 :E，P，T，G，M，K。 您 还 可 以 使 用 两 个 字母 的 等 效 的 因数 : Ei， 
Pi> Ti > Gi> Mi» Kie 例 如， 以 下 代表 大 致 相同 的 值 : 


128974848, 129e6, 129M, 123Mi 


下 面 是 个 例子 。 


以 下 Pod 有 两 个 容器 。 每 个 容器 的 请 求 为 0.25 cpu 和 64MB (226 FH) HA? 
每 个 容器 的 限制 为 0.5 cpu 和 128MiB 内 存 。 您 可 以 说 该 Pod 请 求 0.5 cpu 和 128 
MiB 的 内 存 ， 限 制 为 1cpu 和 256MiB 的 内 存 。 


apiVersion: v1 


kind: Pod 
metadata: 
name: frontend 
spec: 
containers: 
- name: db 
image: mysql 
resources: 
requests: 
memory: "64Mi" 
cpu: "250m" 
limits: 
memory: "128Mi" 
cpu: "500m" 
- name: wp 
image: wordpress 
resources: 
requests: 
memory: "64Mi" 
cpu: "250m" 
limits: 
memory: "128Mi" 
cpu: "500m" 


具有 资源 请 求 的 Pod 如 何 调度 


当 您 创建 一 个 Pod 时 ，Kubernetes 调度 程序 将 为 Pod 选择 一 个 节点 。 每 个 节点 具 
有 每 种 资源 类 型 的 最 大 容量 : TA Pod 提供 的 CPU 和 内 存量 。 调 度 程序 确保 对 于 
每 种 资源 类 型 ， 调 度 的 容器 的 资源 请 求 的 总 和 小 于 节点 的 容量 。 请 注意 ， 尽 管 节 点 
上 的 实际 内 存 或 CPU 资源 使 用 量 非常 低 ， 但 如 果 容 量 检 查 失败 ， 则 调度 程序 仍然 
拒绝 在 该 节点 上 放置 Pod。 当 资源 使 用 量 稍 后 增加 时 ， 例 如 在 请 求 率 的 每 日 峰值 期 
间 ， 这 可 以 防止 节点 上 的 资源 短缺 。 


具有 资源 限制 的 Pod 如 何 运行 
当 kubelet 启动 一 个 Pod 的 容器 时 ， 它 会 将 CPU 和 内 存 限 制 传递 到 容器 运行 时 。 


当 使 用 Docker 时 : 


e spec.containers[].resources.requests.cpu 的 值 将 转换 成 millicore 
值 ， 这 是 个 浮 点 数 ， 并 乘 以 {1024， 这 个 数字 中 的 较 大 者 或 2 用 作 docker 
run 命令 中 的 --cpu-shares 标志 的 值 。 


e spec.containers[].resources.limits.cpu 被 转换 成 millicore 4& ° 2X # 
以 100000 然后 除 以 1000。 这 个 数字 用 作 docker run 命令 中 的 --cpu- 
quota 标志 的 值 。[ --cpu-quota ] 标志 被 设置 成 了 100000， 表 示 测 量 配额 
使 用 的 默认 100ms 周期 。 如 果 [ --cpu-cfs-quota ] 标志 设置 为 true， 则 
kubelet 会 强制 执行 cpu 限制 。 从 Kubernetes 1.2 版 本 起 ， 此 标志 默认 为 
true ° 

e spec.containers[].resources.limits.memory 被 转换 为 整 型 ， 作 为 

docker run 命令 中 的 --memory 标志 的 值 。 


如 果 容器 超过 其 内 存 限制 ， 则 可 能 会 被 终止 。 如 果 可 重新 启动 ， 则 与 所 有 其 他 类 型 
的 运行 时 故障 一 样 ，kubelet 将 重新 启动 它 


如 果 一 个 容器 超过 其 内 存 请 求 ， 那 么 当 节点 内 存 不 足 时 ， 它 的 Pod 可 能 被 逐 出 。 


能 被 允许 也 可 能 不 被 允许 超过 其 CPU 限制 时 间 。 但 是 ， 由 于 CPU 使 用 率 过 
à ， 不 会 被 杀 死 。 


要 确定 容器 是 否 由 于 资源 限制 而 无 法 安排 或 被 杀 死 ， 请 参阅 疑难 解答 部 分 。 


监控 计算 资源 使 用 


Pod 的 资源 使 用 情况 被 报告 为 Pod 状态 的 一 部 分 。 


如 果 为 集群 配置 了 可 选 监控 ， 则 可 以 从 监控 系统 检索 Pod 资源 的 使 用 情况 。 


^ 


我 的 Pod 处 于 pending 状态 且 事 件 信 息 显 
failedScheduling 


如 果 调 度 器 找 不 到 任何 该 Pod 可 以 匹配 的 节点 ， 则 该 Pod 将 保持 不 可 调度 状态 ， 
直到 找到 一 个 可 以 被 调度 到 的 位 置 。 每 当 调 度 器 找 不 到 Pod 可 以 调度 的 地 方 时 ， 会 
产生 一 个 事件 ， 如 下 所 示 : 


$ kubectl describe pod frontend | grep -A 3 Events 
Events: 


FirstSeen LastSeen Count From Subobject PathReas 
on Message 
36s 5s 6 {scheduler } FailedScheduling 


Failed for reason PodExceedsFreeCPU and possibly others 


在 上 述 示例 中 ， 由 于 节点 上 的 CPU XR A57 “frontend” 的 Pod 将 无 法 调 

度 。 由 于 内 存 不 足 (PodExceedsFreeMemory) ， 类 似 的 错误 消息 也 可 能 会 导致 失 
败 。 一 般 来 说 ， 如 果 有 这 种 类 型 的 消息 而 处 于 pending 状态 ， 您 可 以 尝试 如 下 几 件 
事情 : 


$ kubectl describe nodes e2e-test-minion-group-41w4 


Name: e2e-test-minion-group-41w4 
[ ... lines removed for clarity ...] 
Capacity: 
alpha. kubernetes.io/nvidia-gpu: 0 
cpu: 2 
memory: 7679792Ki 
pods: 110 
Allocatable: 
alpha. kubernetes.io/nvidia-gpu: 0 
Cpu: 1800m 
memory: 7474992Ki 
pods: 110 
[ ... lines removed for clarity ...] 
Non-terminated Pods: (5 in total) 
Namespace Name CPU Request 


s CPU Limits Memory Requests Memory Limits 


kube-system fluentd-gcp-v1i.38-28bv1 100m (5%) 
© (0%) 200Mi (2%) 200Mi (2%) 

kube-system kube-dns-3297075139-611j3 260m (13%) 
0 (0%) 100Mi (1%) 170Mi (2%) 

kube-system kube-proxy-e2e-test-... 100m (5%) 
© (0%) © (0%) © (0%) 

kube-system monitoring-influxdb-grafana-v4-zim12 200m (10%) 
200m (10%)  600Mi (8%) 600Mi (8%) 

kube-system node-problem-detector-v0.1-fj7m3 20m (1%) 
200m (10%)  20Mi (0%) 100Mi (1%) 


Allocated resources: 
(Total limits may be over 100 percent, i.e., overcommitted.) 
CPU Requests CPU Limits Memory Requests Memory Limits 


680m (34%) 400m (20%) 920Mi (129) 1070Mi (149) 


我 的 容器 被 终结 了 


您 的 容器 可 能 因为 资源 枯 竟 而 被 终结 了 。 要 查看 容器 是 否 因 为 遇 到 资源 限制 而 被 杀 
死 ， 请 在 相关 的 Pod 上 调用 kubectl describe pod 


[12:54:41] $ kubectl describe pod simmemleak-hra99 


Name: simmemleak-hra99 
Namespace: default 
Image(s): saadali/simmemleak 
Node: kubernetes-node-tf0f/10.240.216. 
66 
Labels: name-simmemleak 
Status: Running 
Reason: 
Message: 
IP: 10.244.2.75 
Replication Controllers: simmemleak (1/1 replicas created) 
Containers: 
simmemleak: 
Image:  saadali/simmemleak 
Limits: 
cpu: 100m 
memory: 50Mi 
State: Running 
Started: Tue, 07 Jul 2015 12:54:41 -0700 
Last Termination State: Terminated 
Exit Code: 1 
Started: Fri, 07 Jul 2015 12:54:30 -0700 
Finished: Fri, 07 Jul 2015 12:54:33 -0700 
Ready: False 
Restart Count: 5 
Conditions: 
Type Status 
Ready False 
Events: 
FirstSeen LastSeen 
Count From SubobjectPath 
Reason Message 
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0 
700 1 [scheduler } 


scheduled Successfully assigned simmemleak-h 
ra99 to kubernetes-node-tfOf 
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0 
700 1 {kubelet kubernetes-node-tfOf) implicitly require 
d container POD pulled Pod container image "gcr.io/google 
_containers/pause:0.8.0" already present on machine 
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0 
700 1 {kubelet kubernetes-node-tfOf) implicitly require 
d container POD created Created with docker id 6a41280f516 


d 
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0 


700 1 {kubelet kubernetes-node-tfOf) implicitly require 
d container POD started Started with docker id 6a41280f516 
d 
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0 
700 1 {kubelet kubernetes-node-tfOf) spec.containers{si 
mmemleak] created Created with docker id 87348f12526 
a 
‘| = J» 








在 上 面 的 例子 中 ， Restart Count: 5 意味 着 Pod 中 的 simmemleak 容器 被 终 
止 并 重启 了 五 次 。 


您 可 以 使 用 kubectl get pod 命令 加 上 -o go-template=... 选项 来 获取 之 
前 终止 容器 的 状态 。 


[13:59:01] $ kubectl get pod -o go-template='{{range.status.cont 
ainerStatuses}}{{"Container Name: "}}{{.name}}{{"\r\nLastState: 
"b}{{.lastState}}{{end}}' simmemleak-60xbc 

Container Name: simmemleak 

LastState: map[terminated:map[exitCode:137 reason:00M Killed sta 
rtedAt:2015-07-07T20:58:43Z finishedAt :2015-07-07T20:58:43Z cont 
ainerID:docker://0e4095bbadifeccdfe7ef9fb6ebffe972b4b14285d5acdec 
efOod3ae8a22fad8b2] | 


您 可 以 看 到 容器 因为 reason:00M killed 被 终止 ， oom 表示 Out Of 
Memory ° 


PA 8H AL EF 79. (Alpha 能 ) 


Kubernetes 1.5 版 本 中 引入 不 透明 整 型 资 ° Pi 透明 的 整数 资源 允许 集群 运 维 人 员 
发 布 新 的 节点 级 资源 ， 否 则 系统 将 不 了 解 这 些 资 源 。 


用 户 可 以 在 Pod 的 spec 中 消费 这 些 资源 ， 就 像 CPU 和 内 存 一 样 。 调 度 器 负责 资 
源 计 量 ， 以 便 在 不 超过 可 用 量 的 同时 分 配给 Pod。 


注意 : 不 透明 整 型 资源 在 kubernetes 1.5 中 还 是 Alpha 版 本 。 只 实现 了 资源 计 
量 ， 节 点 级 别 的 隔离 还 处 于 积极 的 开发 阶段 。 


不 透明 整 型 资源 是 以 pod.alpha.kubernetes.io/opaque-int-resource- 为 前 
组 的 资源 。API server 将 限制 这 些 资源 的 数量 为 整数 。 有 效 数量 的 例子 有 
3 ^ 3000m 和 3Ki 。 无 效 数量 的 例子 有 0.5 和 1500m ° 


申请 使 用 不 透明 整 型 资源 需要 两 步 。 首 先 ， 集群 运 维 人 员 必 须 在 一 个 或 多 个 节点 上 
通告 每 个 节点 不 透明 的 资源 。 然 后 ， 用 户 必须 在 Pod 中 请 求 不 透明 资源 。 


要 发 布 新 的 不 透明 整 型 资源 ， 集 群 运 维 人 员 应 向 API server 提交 PATCH HTTP 请 
求 ， 以 指定 集群 中 节点 的 status.capacity 的 可 用 数量 。 在 此 操作 之 后 ， 节 点 的 
status.capacity 将 包括 一 个 新 的 资源 。 status.allocatable (jn 
kubelet 异步 地 使 用 新 资源 自动 更 新 。 请 注意 ， 由 于 调度 器 在 评估 Pod 适应 度 时 使 
用 节点 status.allocatable 值 ， 所 以 在 使 用 新 资源 修补 节点 容量 和 请 节 
点 上 调度 资源 的 第 一 个 pod 之 间 可 能 会 有 短暂 的 延迟 。 


示例 


日 


这 是 一 个 HTTP 请 求 ，master 节点 是 k8s-master， 在 k8s-node-1 节点 上 通告 5 个 
“foo” 资 源 。 


PATCH /api/vi/nodes/k8s-node-1/status HTTP/1.1 
Accept: application/json 

Content-Type: application/json-patch+json 
Host: k8s-master:8080 


[ 


{ 
"op" : "add", 
"path": "/status/capacity/pod.alpha.kubernetes.io-10paque-in 
t-resource-foo", 
"value" 3 "pn 
} 


] 


curl --header "Content-Type: application/json-patch+json" \ 
--request PATCH \ 

--data '[{"op": "add", "path": "/status/capacity/pod.alpha.kuber 
netes.io-10paque-int-resource-foo", "value": "5"}]' N 
http://k8s-master :8080/api/vi/nodes/k8s-node-1/status 


注意 : 在 前 面 的 请 求 中 ， ~1 是 patch 路 径 中 / 字符 的 编码 。JSON-Patch 中 
的 操作 路 径 值 被 解释 为 JSON-Pointer。 更 多 详细 信息 请 参阅 IETF RFC 6901, 
section 3 ° 


apiVersion: v1 
kind: Pod 
metadata: 
name: my-pod 
spec: 

containers: 

- name: my-container 
image: myimage 
resources: 

requests: 
cpu: 2 
pod.alpha.kubernetes.io/opaque-int-resource-foo: 1 


计划 改进 


在 kubernetes 1.5 版 本 中 仅 人 允许 在 容器 定 资源 量 。 计 划 改 进 对 所 有 容器 在 Pod 
中 共 i d m HOM 


在 kubernetes 1.5 版 本 中 仅 支 持 容器 对 CPU 和 内 存 的 申请 和 限制 。 计 划 增 加 新 的 
资源 类 型 ， 包 括 节点 磁盘 空间 资源 和 一 个 可 支持 自 定义 资源 类 型 的 框架 。 


Kubernetes 通过 支持 通过 多 级 别 的 服务 质量 来 支持 资源 的 过 度 使 用 。 


在 kubernetes 1.5 版 本 中 ， 一 个 CPU 单位 在 不 同 的 云 提供 商 和 同一 云 提 供 商 的 不 

同 机 器 类 型 中 的 意味 都 不 同 。 例 如 ， 在 AWS 上 ， 节 点 的 容量 报告 为 ECU， 而 在 

GCE 中 报告 为 逻辑 内 核 。 我 们 计划 修改 cou 资源 的 定义 ， 以 便 在 不 同 的 提供 商 和 
台 之 间 保 持 一 致 。 
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集群 联邦 


Kubernetes v1.9 声 称 单 集群 最 多 可 支持 5000 个 节点 和 15 万 个 Pod， 我 相信 很 少 有 公 

司 会 部 署 如 此 庞大 的 一 个 单 集群 ， 总 有 很 多 情况 下 因为 各 种 各 样 的 原因 我 们 可 能 会 

部 署 多 个 集群 ， 但 是 有 时 候 有 想 将 他 们 统一 起 来 管理 ， 这 时 候 就 需要 用 到 集群 联邦 
(Federation ) 。 


为 什么 要 使 用 federation 


Federation 使 管理 多 个 集群 变 得 简单 。 它 通过 提供 两 个 主要 构建 模块 来 实现 : 


e. 跨 集群 同步 资源 : Federation 提供 了 在 多 个 集群 中 保持 资源 同步 的 能 力 。 例 
如 ， 可 以 保证 同一 个 deployment 在 多 个 集群 中 存在 。 

e 跨 集 群 服务 发 现 : Federation 提供 了 自动 配置 DNS 服务 以 及 在 所 有 集群 后 端 
上 进行 负载 均衡 的 能 力 。 例 如 ， 可 以 提供 一 个 全 局 VIP 或 者 DNS 记录 ， 通 过 
它 可 以 访问 多 个 集群 后 端 。 


Federation 还 可 以 提供 一 些 其 它 用 例 : 


e 高 可 用 : 通过 在 集群 问 分布 负载 并 自动 配置 DNS 服务 和 负载 均衡 ，federation 
最 大 限度 地 减少 rnd B 


e 避免 厂商 锁定 : 通过 更 简单 的 跨 集 群 应 用 迁移 方式 ，federation 可 以 防止 集群 
厂商 锁定 。 
Federation 对 于 单个 集群 没有 用 处 。 基 于 下 面 这 些 原 因 您 可 能 会 需要 多 个 集群 : 


e RER : 通过 在 多 个 区 域 部 署 集 群 可 以 最 大 限度 减少 区 域 近 端 用 户 的 延迟 。 

e 故障 隔离 : 拥有 多 个 小 集群 可 能 比 单个 大 集群 更 利于 故障 隔离 (例如 : 在 云 服 
务 提供 商 的 不 同 可 用 区 中 的 多 个 集群 )。 详 情 请 参考 乡 集群 指南 

e 可 伸缩 性 : 单个 集群 有 可 伸缩 性 限制 (对 于 大 多 数 用 户 这 不 是 典型 场景 。 更 多 
细节 请 参考 Kubernetes 弹性 伸缩 与 性 能 目标 ) 。 

e RAZ: 您 可 以 在 不 同 的 云 服 务 提供 商 或 本 地 数据 中 心中 拥有 多 个 集群 。 


告 


ok 


& /4 federation 有 很 多 吸引 人 的 使 用 案例 ， 但 也 有 一 些 注 意 事项 : 


e 增加 网 络 带宽 和 成 本 : federation 控制 平面 监控 所 有 集群 pace: 前 dne 符合 
预期 。 如 果 集 群 在 云 服 务 提 供 商 的 不 同 区 域 或 者 不 同 的 云 服 务 提供 商 上 运行 
时 ， 这 将 导致 明显 的 网 络 成 本 增加 。 

e 减少 跨 集群 隔离 : federation 控制 平面 中 的 bug 可 能 影响 所 有 集群 。 通 过 在 
federation 中 实现 最 少 的 逻辑 可 以 缓解 这 种 情况 。 只 要 有 可 能 ， 它 就 将 尽力 把 
工作 委托 给 kubernetes 集群 中 的 控制 平面 。 这 种 设计 和 实现 在 安全 性 及 避免 
多 集群 停止 运行 上 也 是 错误 的 。 

e RAŽ : federation 项 目 相 对 比较 新 ， 还 不 是 很 成 熟 。 并 不 是 所 有 资源 都 可 
用 ， 许 多 仍然 处 于 alpha 状态 。 Issue 88 列举 了 团队 目前 正 忙于 解决 的 与 系统 
相关 的 已 知 问题 。 


Kubernetes 集群 federation 可 以 包含 运行 在 不 同 云 服务 提供 商 (例如 Google 
Cloud ` AWS) 及 本 地 (例如 在 OpenStack 上 ) 的 集群 。 Hie 需要 按 需 在 适合 的 云 
服务 提供 商 和 /或 地 点 上 简单 的 创建 集群 ， 然 后 向 Federation API Server 注册 每 个 

集群 的 API endpoint 和 凭据 即 可 。 (详细 信息 请 参阅 federation 管理 指南 ) 。 


此 后 ， 您 的 AP] 资源 就 可 以 跨越 不 同 的 集群 和 云 服务 提供 商 


设置 federation 


为 了 能 够 联合 (federate) 多 个 集群 ， 首 先 需 要 建立 一 个 federation 控制 平面 。 请 
按照 设置 指南 设置 federation 控制 平面 。 


API 资源 


一 旦 设置 了 控制 平面 ， 您 就 可 以 开始 创建 federation API 资源 。 以 下 指南 详细 介绍 
了 一 些 资源 : 


e Cluster 

e ConfigMap 
e DaemonSets 
e Deployment 
e Events 

e Hpa 


e Ingress 

e Jobs 

e Namespaces 
e ReplicaSets 
e Secrets 

e Services 


API 参考 文档 列举 了 federation apiserver 支持 的 所 有 资源 。 


级 联 删 除 


Kubernetes 1.6 版 本 包括 了 对 联邦 资源 (federated resources) 级 联 删 除 的 支持 。 
通过 级 联 删除 ， 当 您 从 federation 控制 平面 删除 一 个 资源 时 ， 会 同时 删除 所 有 底层 
集群 中 对 应 的 资源 。 


当 使 用 REST API 时 ， 级 联 删 除 没有 默认 开启 。 要 想 在 使 用 REST API 从 
federation 控制 平面 删除 资源 时 启用 级 联 删除 ds 

DeleteOptions. MP AMAN 选项 。 使 用 kubectl delete 时 
默认 使 用 级 联 删 除 。 您 可 以 通过 运行 kubectl delete --cascade-false 来 禁 
用 该 功能 。 


注意 : Kubernetes 1.5 版 本 支持 的 级 联 删 除 仅 支持 部 分 federation 资源 。 


单个 集群 范围 


在 诸如 Google Compute Engine 或 者 Amazon Web Services 等 laaS 服务 提供 商 
中 ， 虚 拟 机 存在 于 区 域 或 可 用 区 上 。 我 们 建议 Kubernetes 集群 中 的 所 有 虚拟 机 
应 该 位 于 相同 的 可 用 区 ， 因 为 : 


e 与 拥有 单个 全 局 Kubernetes 集群 相 比 ， 单 点 故障 更 少 。 

e 与 跨 可 用 区 集群 相 比 ， 推 测 单 区 域 集群 的 可 用 性 属性 更 容易 。 

e 当 Kubernetes 开发 人 员 设 计 系统 时 (例如 对 延迟 ， 带 宽 或 相关 故障 进行 假 
设 ) ， 它 们 假设 所 有 的 机 器 都 在 一 个 单一 的 数据 中 心 ， 或 以 其 它 方式 紧密 连 
接 。 


在 每 个 可 用 区 域 同时 拥有 多 个 集群 也 是 可 以 的 ， 但 总 体 而 言 ， 我 们 认为 少 一 点 更 
好 。 选择 较 少 集群 的 理由 是 : 


e 某 些 情况 下 ， 在 一 个 集群 中 拥有 更 多 的 节点 可 以 改进 Pod 的 装 箱 打 包 ( 较 少 资 
源 碎片 ) 。 

e 减少 运 维 开 销 (尽管 随 着 运 维 工具 和 流程 的 成 熟 ， 优 势 已 经 减少 ) 。 

e. 减少 每 个 集群 国定 资源 成 本 的 开销 ， 例 如 apiserver 虚拟 机 (但 对 于 大 中 型 集 
群 的 整体 集群 成 本 来 说 百分比 很 小 ) 。 


拥有 多 个 集群 的 原因 包括 : 


e 严格 的 安全 策略 要 求 将 一 类 工作 与 另 一 类 工作 隔离 开 来 (但 是 ， 请 参见 下 面 的 
分 区 集群 (Partitioning Clusters) ) 。 
e 对 新 的 Kubernetes 发 行 版 或 其 它 集群 软件 进行 灰 度 测试 。 


选择 正确 的 集群 数量 


Kubernetes 集群 数量 的 选择 可 能 是 一 个 相对 静态 的 选择 ， 只 是 偶尔 重新 设置 。 相 比 
之 下 ， 依 据 负 载 情况 和 增长 ， 集 群 的 节点 数量 和 service 的 pod 数量 可 能 会 经 常 变 
化 。 


要 选择 集群 的 数量 ， 首 先 要 确定 使 用 哪些 区 域 ， 以 便 为 所 有 终端 用 户 提供 足够 低 的 
延迟 ， 以 在 Kubernetes 上 运行 服务 (如 果 您 使 用 内 容 分 发 网 络 (Content 
Distribution Network > CDN) ， 则 CDN 托管 内 容 的 时 延 要 求 不 需要 考虑 ) 。 法 律 
问题 也 可 能 影响 到 这 一 点 。 例 如 ， 拥 有 全 球 客 户 群 的 公司 可 能 会 决定 在 美国 、 欧 
盟 、 亚 太 和 南亚 地 区 拥有 集群 。 我 们 将 选择 的 区 域 数量 称 为 R 。 


其 次 ， 决 定 在 整体 仍然 可 用 的 前 提 下 ， 可 以 同时 有 多 少 集群 不 可 用 。 将 不 可 用 集群 
的 数量 称 为 U 。 如 果 您 不 能 确定 ， 那 么 1 是 一 个 不 错 的 选择 。 


如 果 在 集群 故障 的 情形 下 允许 负载 均衡 将 流量 引导 到 任何 区 域 ， 则 至 少 需要 有 上 比 
R 或 U + 1 数量 更 大 的 集群 。 如 果 不 行 的 话 (例如 希望 在 集群 发 生 故 障 时 对 所 
有 用 户 确 保 低 延迟 ) ， 那 么 您 需要 有 数量 为 R * (U + 1) 的 集群 ( R 个 区 域 ， 
每 个 中 有 U + 1 个 集群 ) 。 无 论 如 何 ， 请 尝试 将 每 个 集群 放 在 不 同 的 区 域 中 。 


最 后 ， 如 果 您 的 任何 集群 需要 比 Kubernetes 集群 最 大 建议 节点 数 更 多 的 节点 ， 那 
么 您 可 能 需要 更 多 的 集群 。Kubernetes v1.3 支持 最 多 1000 个 节点 的 集群 。 
Kubernetes v1.8 支持 最 多 5000 个 节点 的 集群 。 更 多 的 指导 请 参见 构建 大 型 集 
群 。 


原文 地 址 : https://kubernetes.io/docs/concepts/cluster-administration/federation/ 


译文 地 址 : https://k8smeetup.github.io/docs/concepts/cluster- 
administration/federation/ 
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GlusterFS 


GlusterFS 是 Scale-Out 存 储 解 决 方案 Gluster 的 核心 ， 它 是 一 个 开源 的 分 布 式 文件 系 
统 ， 具 有 强大 的 横向 扩展 能 力 ， 通 过 扩展 能 够 支持 数 PB 存 储 容 量 和 处 理 数 千 客户 
端 。GlusterFS 借 助 TCP/HIP 或 InfiniBand RDMA 网 络 将 物理 分 布 的 存储 资源 聚集 在 一 
起 ， 使 用 单一 全 局 命名 空间 来 管理 数据 。GlusterFS 基 于 可 堆 且 的 用 户 空 间 设 计 ， 
可 为 各 种 不 同 的 数据 负载 提供 优异 的 性 能 。 
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使 用 glusterfs 做 持久 化 存储 


我 们 复 用 kubernetes 的 三 台 主 机 做 glusterfs 存 储 。 


以 下 步骤 参考 自 : https://www.xf80.com/2017/04/21/kubernetes-glusterfs/ (该 网 站 
已 无 法 访问 ) 


安装 glusterfs 


我 们 直接 在 物理 机 上 使 用 yum 安 装 ， 如 果 你 选择 在 kubernetes 上 安装 ， 请 参 
考 + https://github.com/gluster/gluster-kubernetes/blob/master/docs/setup- 
guide.md 


A 先 安 装 gluster # 
$ yum install centos-release-gluster -y 


# 安装 glusterfs 组 件 
$ yum install -y glusterfs glusterfs-server glusterfs-fuse glust 
erfs-rdma glusterfs-geo-replication glusterfs-devel 


## 创建 glusterfs 目录 

$ mkdir /opt/glusterd 

## 修改 glusterd HR 

$ sed -i 'S/var\/lib/opt/g' /etc/glusterfs/glusterd.vol 
# 后 动 glusterfs 

$ systemctl start glusterd.service 
# 设置 开机 启动 

$ systemctl enable glusterd.service 
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$ systemctl status glusterd.service 


配置 glusterfs 


# 配置 hosts 


$ vi /etc/hosts 

172.20.0.113 test-001.jimmysong.io 
172.20.0.114 test-002.jimmysong.io 
172.20.0.115 test-003.jimmysong.io 


u tay 
WF Diy 一 


$ iptables -I INPUT -p tcp --dport 24007 -j ACCEPT 
# A 建 & fü 诸 目录 


$ mkdir /opt/gfs_data 


23] Adan x 4 


4j F 小 机 AS 需要 probe 小 机 
[roetütese: 001 J 
gluster peer probe test-002.jimmysong.io 
gluster peer probe test-003.jimmysong.io 





A 查看 集群 状态 
$ gluster peer status 
Number of Peers: 2 


Hostname: test-002.jimmysong.io 
Uuid: f25546cc-2011-457d-ba24-342554b51317 
State: Peer in Cluster (Connected) 


Hostname: test-003.jimmysong.io 
Uuid: 42b6cadi1-aa01-46d0-bbba-f7ece821d66d 
State: Peer in Cluster (Connected) 


配置 volume 


GlusterFS 中 的 volume 的 模式 有 很 多 中 ， 包 括 以 下 几 种 : 


e 分 布 卷 (RUN) : 即 DHT, 也 叫 分布 卷 : 将 文件 已 hash 算 法 随机 分 布 到 一 
台 服 务 器 节点 中 存储 。 

e 复制 模式 : 即 AFR, 创建 volume 时 带 replica x 数量 : 将 文件 复制 到 replica x 个 
Ye 

e 条 带 模 式 : 即 Striped, 创建 volume H1 # stripe x 数量 : 将 文件 切割 成 数据 块 ， 
分 别 存储 到 stripe x 个 节点 中 ( 类似 raid 0 ) ° 

e 分 布 式 条 带 模式 : 最 少 E246852156 | 建 。 创建 volume 时 stripe 2 


server =4 个 节点 : 2 DHT 4 Striped 的 组 合 型 。 

e 分 布 式 复制 模式 : 最 少 需要 4 台 服 务 器 才能 创建 。 € volume 时 replica 2 
server = 4 个 节点 : 是 DHT 与 AFR 的 组 合 型 。 

e 条 带 复 制 卷 模 式 : 最 少 需要 4 台 服 务 器 才能 创建 。 创建 volume 时 stripe 2 
replica 2 server 2 4 个 节点 : X Striped 5 AFR 的 组 合 型 。 

e 三 种 模式 混合 : 至 少 需要 8 台 服务 器 才能 创建 。 stripe 2 replica 2, 每 4 个 节点 
组 成 一 个 组 。 


这 几 种 模式 的 示例 图 参考 : CentOS7 € € GlusterFS ° 


因为 我 们 只 有 三 人 台 主 机 ， 在 此 我 们 使 用 默认 的 分 布 卷 模 式 。 请 勿 在 生产 环境 上 使 用 
该 模式 ， 容 易 导 致 数据 丢失 。 


4 NETA s 
$ gluster volume create k8s-volume transport tcp test-001.jimmys 
ong.io:/opt/gfs data test-002.jimmysong.io:/opt/gfs data test-00 


3.jimmysong.io:/opt/gfs data force 


+ $4 volume43.5 

$ gluster volume info 

Volume Name: k8s-volume 

Type: Distribute 

Volume ID: 9a3b0710-4565-4eb7-abae-1d5c8ed625ac 
Status: Created 

Snapshot Count: 0 

Number of Bricks: 3 

Transport-type: tcp 

Bricks: 

Bricki: test-001.jimmysong.io:/opt/gfs data 
Brick2: test-002.jimmysong.io:/opt/gfs data 
Brick3: test-003.jimmysong.io:/opt/gfs data 
Options Reconfigured: 
transport.address-family: inet 

nfs.disable: on 


$ gluster volume start k8s-volume 
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+ 


L4 
LL 


LL 
77 
77 


$ 


| 指定 volume 的 配额 
gluster volume quota k8s-volume enable 


限制 指定 volume 的 配额 
gluster volume quota k8s-volume limit-usage / 1TB 


cache 大 小 ， 黑 认 32MB 
gluster volume set k8s-volume performance.cache-size 4GB 

io Af, AKAFSRMB A 
gluster volume set k8s- volume performance.io-thread-count 16 
Pa 网 络 检测 时 间 ， 默认 4235 
glaster volume set k8s-volume network.ping-timeout 10 
tE 写 缓冲 区 的 大 小 RUIM 


上 volume set k8s-volume performance.write-behind-window- 


size 1024MB 


Kubernetes ¥ & E glusterfs 


官方 


的 文档 


见 : https://github.com/kubernetes/kubernetes/tree/master/examples/volumes/glus 


terfs 


以 下 
其 中 


用 到 的 所 有 yaml 和 json 配 置 文件 可 以 在 .Jmanifests/glusterfs 中 找到 。 注 意 替换 
私有 镜像 地 址 为 你 自己 的 镜像 地 址 。 


kubernetes 安 装 客 户 端 


$ 


$ 


在 所 有 k8s node T € € glusterfs ZP 3m 
yum install -y glusterfs glusterfs-fuse 
LE hosts 


vi /etc/hosts 


172.20.0.113 test-001.jimmysong.io 
172.20.0.114 test-002.jimmysong.io 
172.20.0.115 test-003.jimmysong.io 


因为 


我 们 glusterfs 跟 kubernetes 集 群 复 用 主机 ， 因 为 此 这 一 步 可 以 省 去 。 


配置 endpoints 


$ curl -O https://raw.githubusercontent.com/kubernetes/kubernete 
s/master/examples/volumes/glusterfs/glusterfs-endpoints.json 


# 修改 endpoints.json ， 配 置 glusters 集群 节点 ip 
4 每 一 个 addresses 为 一 个 ip 组 


{ 


"addresses": [ 


"Ap": "1/2.22,.,0.112" 


} 

l; 

"ports": [ 
{ 

"port": 1990 

} 

] 

}, 


# 导入 glusterfs-endpoints.json 
$ kubectl apply -f glusterfs-endpoints.json 


# 查看 endpoints 信息 
$ kubectl get ep 


配置 service 


$ curl -O https://raw.githubusercontent.com/kubernetes/kubernete 
s/master/examples/volumes/glusterfs/glusterfs-service.json 


A service.json 里 面 查找 的 是 enpointes 的 名 称 与 端口 ， 端 口 默认 配置 为 1? 
我 改 成 了 1990 


# 导入 glusterfs-service.json 
$ kubectl apply -f glusterfs-service.json 


# 查看 service 信息 
$ kubectl get svc 


创建 测试 pod 


$ curl -O https://raw.githubusercontent.com/kubernetes/kubernete 
s/master/examples/volumes/glusterfs/glusterfs-pod.json 


# 编辑 glusterfs-pod.json 
# 修改 volumes 下 的 path 


y 


为 上 面 创建 的 volume 名 称 
"path": "k8s-volume" 


# 导入 glusterfs-pod.json 
$ kubectl apply -f glusterfs-pod.json 


# 查看 pods 状态 

$ kubectl get pods 

NAME READY STATUS RESTARTS 
AGE 

glusterfs 1/1 Running 0 

1m 

# 查看 pods 所 在 node 


$ kubectl describe pods/glusterfs 


# 登陆 node 物理 机 ， 使 用 df 可 查看 挂 载 目录 

$ df -h 

172.20.0.113:k8s-volume 1073741824 0 1073741824 0% 172. 
20.0.113:k8s-volume 1.0T © 1.0T 0% /var/lib/kubelet/pods 


/3de9fc69-30b7 -11e7 -bfbd -8afie3a7c5bd/volumes/kubernetes.io~glus 
terfs/glusterfsvol 


Ac à PersistentVolume 


PersistentVolume (PV) 和 PersistentVolumeClaim (PVC) 是 kubernetes 提 供 的 
两 种 API 资 源 ， 用 于 抽象 存储 细节 。 管 理 员 关 注 于 如 何 通过 pv 提供 存储 功能 而 无 需 
关注 用 户 如何 使 用 ， 同 样 的 用 户 只 需要 挂 载 PVC 到 容器 中 而 不 需要 关注 存储 卷 采 用 
何 种 技术 实现 。 


PVC 和 PV 的 关系 跟 pod 和 node 关 系 类 似 ， 前 者 消耗 后 者 的 资源 。PVC 可 以 向 PV 申 
请 指定 大 小 的 存储 资源 并 设置 访问 模式 。 

PV 属性 

e Storage 容 量 


。 读 写 属性 : 分 别 为 ReadWriteOnce : 单个 节点 读 写 ; ReadOnlyMany : 多 节点 
只 读 ; ReadWriteMany : 多 节点 读 写 


$ cat glusterfs-pv.yaml 
apiVersion: vi 
kind: PersistentVolume 
metadata: 
name: gluster-dev-volume 
spec: 
capacity: 
storage: 86i 
accessModes: 
- ReadwriteMany 
glusterfs: 
endpoints: "glusterfs-cluster" 
path: "k8s-volume" 
readOnly: false 


# 导入 PV 
$ kubectl apply -f glusterfs-pv.yaml 


# pv 


$ kubect1 get pv 


NAME CAPACITY ACCESSMODES RECLAIMPOLICY 
ATUS CLAIM STORAGECLASS REASON AGE 
gluster-dev-volume 8Gi RWX Retain 
ailable 3s 

PVC 属 性 


e 访问 属性 与 PV 相同 


。 容量 : 向 PV 申 请 的 容量 <= PV 总 容量 


Ac 2 PVC 


$ cat glusterfs-pvc.yaml 
kind: PersistentVolumeClaim 
apiVersion: vi 
metadata: 
name: glusterfs-nginx 
spec: 
accessModes: 
- ReadwriteMany 
resources: 
requests: 
storage: 8Gi 


# $A pvc 

$ kubectl apply -f glusterfs-pvc.yaml 

# 查看 pve 

$ kubectl get pv 

NAME STATUS VOLUME CAPACITY ACCE 

SSMODES STORAGECLASS AGE 

glusterfs-nginx Bound gluster-dev-volume 8Gi RWX 
As 


创建 nginx deployment 1€ # volume 


$ vi nginx-deployment.yaml 
apiVersion: extensions/vibeta1 
kind: Deployment 
metadata: 
name: nginx-dm 
spec: 
replicas: 2 
template: 
metadata: 
labels: 
name: nginx 
spec: 
containers: 
- name: nginx 
image: nginx:alpine 
imagePullPolicy: IfNotPresent 
ports: 
- containerPort: 80 
volumeMounts: 
- name: gluster-dev-volume 
mountPath: "/usr/share/nginx/html" 
volumes: 
- name: gluster-dev-volume 
persistentVolumeClaim: 


claimName: glusterfs-nginx 


# +A deployment 
$ kubectl apply -f nginx-deployment.yaml 


4 查看 deployment 
$ kubectl get pods |grep nginx-dm 


nginx-dm-3698525684-gOmvt 1/1 Running 0 6 
S 

nginx -dm-3698525684-hbzq1 1/1 Running 0 6 
S 

# 查看 ER 


$ kubectl exec -it nginx-dm-3698525684-gOmvt -- df -h|grep k8s-v 
olume 

172.20.0.113:k8s-volume 1.0T © 1.0T 0% /usr/share 
/nginx/html 


s 创建 文件 测试 
$ kubectl exec -it nginx-dm-3698525684-gOmvt -- touch /usr/share 
/nginx/html/index.html 


$ kubectl exec -it nginx-dm-3698525684-gOmvt -- ls -lt /usr/shar 
e/nginx/html/index.html 

-rw-r--r-- 1 root root 0 May 4 11:36 /usr/share/nginx/html/inde 
x.html 


# 验证 glusterfs 

# 因为 我 们 使 用 分 布 卷 ， 所 以 可 以 看 到 某 个 节点 中 有 文件 
[root@test-001 ~] ls /opt/gfs_data/ 
[root@test-002 ~] ls /opt/gfs data/ 
index.html 

[root@test-003 ~] ls /opt/gfs data/ 


e CentOS 7 安装 GlusterFS 


e GlusterFS with kubernetes 
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使 用 Heketi 作 为 kubernetes 的 持久 存储 
GlusterFS 的 external 

provisioner (Kubernetes 集 成 GlusterFS 集 
群 和 Heketi) 


本 文 翻译 自 heketi 的 github 网 址 官方 文档 (大 部 分 为 google 翻 译 ， 少 许 人 工 调 整 ， 括 
号 内 为 个 人 注解 ) 其 中 注意 事项 部 分 为 其 他 网 上 查询 所 得 。 本 文 的 整个 过 程 将 在 
kubernetes 集 群 上 的 3 个 或 以 上 节点 安装 glusterfs 的 服务 端 集群 (DaemonSet 方 

AX) ， 并 将 heketi 以 deployment 的 方式 部 署 到 kubernetes 集 群 。 在 我 的 示例 部 分 有 
StorageClass 和 PVC 的 样 例 。 本 文 介绍 的 Heketi，GlusterFS 这 2 个 组 件 与 
kubernetes 集 成 只 适合 用 于 测试 验证 环境 ， 并 不 适合 生产 环境 ， 请 注意 这 一 点 。 


Heketi 是 一 个 具有 resetful 接 口 的 glusterfs 管 理 程序 ， 作 为 kubernetes 的 Storage 存 储 
的 external provisioner。“Heketi 提 供 了 一 个 RESTful 管 理 界 面 ， 可 用 于 管理 
GlusterFS 卷 的 生命 周期 。 借 助 Heketi， 像 OpenStack Manila > Kubernetes e 
OpenShift 这 样 的 云 服务 可 以 动态 地 配置 GlusterFS 卷 和 任何 支持 的 持久 性 类 型 。 
Heketi 将 自动 确定 整个 集群 的 brick 位 置 ， 确 保 将 brick 及 其 副本 放置 在 不 同 的 故障 域 
中 。Heketi 还 支持 任意 数量 的 GlusterFS 集 群 ， 允 许 云 服务 提供 网 络 文件 存储 ， 而 不 
受 限于 单个 GlusterFS 集 群 。” 


注意 事项 


e 安装 Glusterfs 客 户 端 : 每 个 kubernetes 集 群 的 节点 需要 安装 gulsterfs 的 客户 
端 ， 如 ubuntu 系统 的 apt-get install glusterfs-client 。 

e 加 载 内 核 模 块 : 每 个 kubernetes 集 群 的 节点 运行 modprobe dm thin pool ， 
加 载 内 核 模 块 。 

e 至 少 三 个 slave 节 点 : 至 少 需要 3 个 kubernetes slave 节 点 用 来 部 署 glusterfs 集 
群 ， 并 且 这 3 个 slave 节 点 每 个 节点 需要 至 少 一 个 空余 的 磁盘 。 


概述 


本 指南 支持 在 Kubernetes 和 集群 中 集成 ， 部 署 和 管理 GlusterFS 容器 化 的 存储 节点 。 
这 使 得 Kubernetes 管 理 员 可 以 为 其 用 户 提供 可 靠 的 共享 存储 。 


跟 这 个 话题 相关 的 另 一 个 重要 资源 是 gluster-kubernetes 项 目 。 它 专注 于 在 
Kubernetes 集 群 中 部 署 GlusterFS， 并 提供 简化 的 工具 来 完成 此 任务 。 它 包含 一 个 
安装 指南 setup guide。 它 还 包括 一 个 样 例 Hello World。 其 中 包含 一 个 使 用 动态 配 
置 (dynamically-provisioned ) 的 GlusterFS 卷 进行 存储 "e server pode eg 
于 那些 想 要 测试 或 学 习 更 多 关于 此 主题 的 人 ， 请 按照 主 README 的 快速 入 门 说 明 
进行 操作 。 


南 旨 在 展示 Heketi 在 Kubernetes 环 境 中 管理 Gluster 的 最 简单 示例 。 这 是 为 了 强 
这 种 配置 的 主要 组 成 组 件 ， 因 此 并 不 适合 生产 环境 。 


基础 设施 要 求 


e 正在 运行 的 Kubernetes 人 集群， 至 少 有 三 个 Kubernetes 工 作 节 点 ， 每 个 节点 至 少 
有 一 个 可 用 的 裸 块 设备 〈 如 EBS 卷 或 本 地 磁盘 ) . 

e 用 于 运行 GlusterFS Pod 的 三 个 Kubernetes 节 点 必须 为 GlusterFS 通 信 打 开 相 应 
的 端口 (如 果 开 启 了 防火 墙 的 情况 下 ， 没 开 防 火 墙 就 不 需要 这 些 操 作 ) 。 在 每 
个 节点 上 运行 以 下 命令 。 

iptables -N heketi 

iptables -A heketi -p tcp -m state --state NEW -m tcp --dpor 
t 24007 -j ACCEPT 

iptables -A heketi -p tcp -m state --state NEW -m tcp --dpor 
t 24008 -j ACCEPT 

iptables -A heketi -p tcp -m state --state NEW -m tcp --dpor 
t 2222 -j ACCEPT 

iptables -A heketi -p tcp -m state --state NEW -m multiport 


--dports 49152:49251 -j ACCEPT 
service iptables save 


EP MRR 


Heketi 提 供 了 一 个 CLI 客 户 端 ， 为 用 户 提供 了 一 种 管理 Kubernetes 中 GlusterFS 的 部 
署 和 配置 的 方法 。 在 客户 端 机 器 上 下 载 并 安装 Download and install the heketi-cli 。 


Glusterfs 和 Heketi 在 Kubernetes 和 集群 中 的 部 署 过 
程 


以 下 所 有 文件 都 位 于 下 方 extras/kubernetes ( git clone 
https://github.com/heketi/heketi.git )° 


e 部 署 GlusterFS DaemonSet 


$ kubectl create -f glusterfs-daemonset.json 


$ kubectl get nodes 


e 通过 设置 storagenode=glusterfs 节 点 上 的 标签 ， 将 gluster 容 器 部 署 到 指定 节点 
Es 


$ kubectl label node <...node...> storagenode=glusterfs 


根据 需要 重复 打 标 签 的 步 又。 验证 Pod 在 节点 上 和 运行 至 少 应 运行 3 个 Pod (因此 至 少 
需要 给 3 个 节点 打 标签 ) 。 


$ kubectl get pods 


e 接 下 来 ， 我 们 将 为 Heketi 创 建 一 个 服务 帐户 〈service-account) : 


$ kubectl create -f heketi-service-account.json 


© 我 们 现在 必须 给 该 服务 帐户 的 授权 绑 定 相应 的 权限 来 控制 gluster 的 pod。 我 们 
通过 为 我 们 新 创建 的 服务 帐户 创建 群集 角色 绑 定 〈cluster role binding) 来 完成 
此 操作 。 


$ kubectl create clusterrolebinding heketi-gluster-admin --clust 
errole=edit --serviceaccount-default:heketi-service-account 


e 现在 我 们 需要 创建 一 个 Kubernetes secret 来 保存 我 们 Heketi 实 例 的 配置 。 必 须 
将 配置 文件 的 执行 程序 设置 为 kubernetes 才 能 让 Heketi server 控 制 gluster 
pod (配置 文件 的 默认 配置 ) 。 除 此 这 些 ， 可 以 尝试 配置 的 其 他 选项 。 


$ kubectl create secret generic heketi-config-secret --from-file= 
./heketi. json 


4 sa 








e 接 下 来 ， 我 们 需要 部 署 一 个 初始 (bootstrap) Pod 和 一 个 服务 来 访问 该 Pod 。 
在 你 用 git 克 隆 的 repo 中 ， 会 有 一 个 heketi-bootstrap.json 文 件 。 


提交 文件 并 验证 一 切 正常 运行 ， 如 下 所 示 : 


# kubectl create -f heketi-bootstrap.json 
service "deploy-heketi" created 
deployment "deploy-heketi" created 


# kubectl get pods 


NAME READY 
STATUS RESTARTS AGE 

deploy-heketi-1211581626-2jotm 1/1 
Running 0 35m 

glusterfs-ip-172-20-0-217.ec2.internal-1217067810-4gsvx 1/1 
Running 0 1h 

glusterfs-ip-172-20-0-218.ec2.internal-2001140516-i9dw9 1/1 
Running 0 1h 

glusterfs-ip-172-20-0-219.ec2.internal-2785213222-q3hba 1/1 
Running 0 1h 


e 当 Bootstrap heketi 服 ons 运行 ， 我 们 配置 端口 转发 ， nen e 
Heketi CLI 与 服务 进行 通信 。 使 用 heketi pod 的 名 称 ， 运 行 下 面 的 命 


kubectl port-forward deploy-heketi-1211581626-2jotm :8080 


如 果 在 运行 命令 的 系统 上 本 地 端口 8080 是 空闲 的 ， 则 可 以 运行 port-forward 命 令 ， 
Maro MUR (2 个 命令 二 选 一 即 可 ， 我 选择 第 二 个 ) 


kubectl port-forward deploy-heketi-1211581626-2jotm 8080:8080 
现在 通过 对 Heketi 服 务 运行 示例 查询 来 验证 端口 转发 是 否 正常 。 该 命令 应 该 已 经 打 
印 了 将 从 其 转发 的 本 地 端口 。 将 其 合并 到 URL 中 以 测试 服务 ， 如 下 所 示 : 


curl http://localhost :8080/hello 
Handling connection for 8080 
Hello from heketi 


最 后 ， 为 Heketi CLI 客 户 端 设 置 一 个 环境 变量 ， 以 便 它 知道 Heketi 服 务 器 的 地 址 。 


export HEKETI_CLI_SERVER=http://localhost : 8080 


e 接 下 来 ， 我 们 将 向 Heketi 提 供 有 关 要 管理 的 GlusterFS 集 群 的 信息 。 通 过 拓扑 文 
件 提供 这 些 信 息 。 克 隆 的 repo 中 有 一 个 示例 拓扑 文件 ， 名 为 topology- 
sample.json。 拓 扑 指定 运行 GlusterFS 容 器 的 Kubernetes 节 点 以 及 每 个 节点 的 
相应 原始 块 设备 。 


确保 hostnames/manage 指 向 如 下 所 示 的 确切 名 称 kubectl get nodes 得 到 的 主机 名 
(如 ubuntu-1) ， 并 且 hostnames/storage 是 存储 网 络 的 IP 地 址 (对 应 ubuntu-1 的 ip 
地 址 ) 。 


IMPORTANT: 重要 提示 ， 目 前 ， 必 须 使 用 与 服务 器 版 本 匹配 的 Heketi-cli 版 本 加 载 


拓扑 文件 。 另 外 ，Heketi pod 带 有 可 以 通过 kubectl exec ... 访问 的 heketi-cli 
副本 。 
修改 拓扑 文件 以 反映 您 所 做 的 选择 ， 然 后 如 下 所 示 部 署 它 (修改 主机 名 ，IP block 


设备 的 名 称 如 xvdg ) 


heketi-client/bin/heketi-cli topology load --json-topology-sampl 
e.json 
Handling connection for 57598 
Found node ip-172-20-0-217.ec2.internal on cluster e6c063ba3 
98f8e9c88a6ed720dc07dd2 
Adding device /dev/xvdg ... OK 
Found node ip-172-20-0-218.ec2.internal on cluster e6c063ba3 
98f8e9c88a6ed720dc07dd2 
Adding device /dev/xvdg ... OK 
Found node ip-172-20-0-219.ec2.internal on cluster e6c063ba3 
98f8e9c88a6ed720dc07dd2 
Adding device /dev/xvdg ... OK 


e 接 下 来 ， 我 们 将 使 用 heketi 为 其 存储 其 数据 库 提 供 一 个 卷 〈 不 要 怀疑 ， 就 是 使 
用 这 个 命令 ，openshift 和 kubernetes 通 用 ， 此 命令 生成 heketi-storage.json 文 


^t) 


4 heketi-client/bin/heketi-cli setup-openshift-heketi-storage 
# kubectl create -f heketi-storage.json 


Pitfall: 注意 ， 如 果 在 运行 setup-openshift-heketi-storage 子 命令 时 heketi-cli 报 
告 “ 无 空间 "错误 ， 则 可 能 无 意 中 运 行 topology load 命 令 的 时 候 服务 端 和 heketi- 
Cli 的 版 本 不 匹配 造成 的 。 停 止 正在 运行 的 heketi pod (kubectl scale 
deployment deploy-heketi --replicas=0) ， 手 动 删除 存储 块 设 备 中 的 任何 签 
名 ， 然 后 继续 运行 heketi pod (kubectl scale deployment deploy-heketi -- 
replicas=1) 。 然 后 用 匹配 版 本 的 heketi-cli 重 新 加 载 拓 扑 ， 然 后 重 试 该 步 又。 


到 作业 完成 后 ， 删 除 bootstrap Heketi 实 例 相 关 的 组 件 : 


# kubectl delete all, service, jobs,deployment, secret --selector=" 
deploy-heketi" 


e 创建 长 期 使 用 的 Heketi 实 例 (存储 持久 化 的 ) 


# kubectl create -f heketi-deployment.json 
service "heketi" created 
deployment "heketi" created 


e 这 样 做 了 以 后 ，heketi db 将 使 用 GlusterFS 卷 ， 并 且 每 当 heketi pod 重 新 启动 时 
都 不 会 重 置 (数据 不 会 丢失 ， 存 储 持久 化 ) © 


使 用 诸如 heketi-cli cluster list 和 的 命令 heketi-cli volume list 来 确认 先前 建立 的 集群 
存在 ， 并 且 heketi 可 以 列 出 在 bootstrap 阶 段 创建 的 db 存储 卷 。 


使 用 样 例 


有 两 种 方法 来 调配 存储 。 常 用 的 方法 是 设置 一 个 StorageClass， 让 Kubernetes 为 提 
交 的 PersistentVolumeClaim 自 动 配置 存储 。 或 者 ， 可 以 通过 Kubernetes 手 动 创建 
和 管理 卷 (PVs) ， 或 直接 使 用 heketi-cli 中 的 卷 。 


参考 gluster-kubernetes hello world example 获取 关于 storageClass 的 更 多 信息 . 


我 的 示例 ( 非 翻 译 部 分 内 容 ) 


e topology 文 件 : 我 的 例子 (3 个 节点 * ubuntu-1 (192.168.5.191) ,ubuntu- 
2 (192.168.5.192) ,ubuntu-3 (192.168.5.193) ,每 个 节点 2 个 磁盘 用 来 做 存储 
(sdb，sdc) ) 


4% A Heketit# A kubernetes 49 44 4. 7 #4 GlusterFS 49 external provisioner 


# cat topology-sample.json 


"clusters": [ 


"nodes": [ 
"node": { 
"hostnames": { 
"manage": [ 
"ubuntu-1" 
] 


"storage": [ 
"192.168.5.191" 


"devices": [ 
"/dev/sdb", 
"/dev/sdc" 


l 
tr 
1 
"node": ( 
"hostnames": ( 
"manage": [ 
"ubuntu-2" 
], 
"storage": [ 
"192.158.5.192" 


] 
ty 


"zone": 1 
Js 


"devices": [ 
"/dev/sdb", 
"/dev/sdc" 


l 
tr 
{ 
"node": { 
"hostnames": { 
"manage": [ 
"ubuntu-3" 
], 
"storage": [ 
"192,168.5.193" 
l 
tr 


843 


"devices": [ 
"/dev/sdb", 
"/dev/sdc" 


e 确认 glusterfs 和 heketi 的 pod 运 行 正常 


# kubectl get pod 
NAME 

STATUS RESTARTS AGE 
glusterfs-gf5zc 


Running 2 8h 
glusterfs-ngc55 

Running 2 8h 
glusterfs-zncjs 

Running 0 2h 
heketi-5c8ffcc756-x9gnv 

Running 5 7h 


e StorageClass yaml x 4t zs 4] 


# cat storage-class-slow.yaml 


apiVersion: storage.k8s.io/vi 
kind: StorageClass 
metadata: 
name: slow 
的 名 字 
provisioner: kubernetes.io/glusterfs 
parameters: 
resturl: "http://10.103.98.75:8080" 
eti servicefjcluster ip 和 端口 
restuser: "admin" 
填 ， 因 为 没有 局 用 鉴 权 模式 
gidMin: "40000" 
gidMax: "50000" 
volumetype: "replicate:3" 
的 默认 为 3 副本 模式 


READY 
1/1 
1/1 
1/1 
1/1 
fio enn mme SC 
Pt eses areas Se hek 
FA erus ah Ioh ge 随便 
#------------- 申请 


e PVC 举例 


# cat pvc-sample.yaml 


kind: PersistentVolumeClaim 
apiVersion: v1 
metadata: 
name: myclaim 
annotations: 
volume.beta.kubernetes.io/storage-class: "slow" # - 
~----------- sch F, 需要 与 storageclass 的 名 字 一 致 
spec: 
accessModes: 
- ReadwriteOnce 
resources: 
requests: 
storage: 1Gi 


查看 创建 的 pvc 和 pv 


# kubectl get pvc|grep myclaim 


NAME STATUS VOLUME 

CAPACITY ACCESS MODES STORAGECLASS AGE 
myclaim Bound pvc -e98e9117 -3ed7-11e8-b61 
d-08002795cb26 16i RWO slow 28s 


# kubectl get pv|grep myclaim 


NAME CAPACITY ACCESS MOD 
ES RECLAIM POLICY STATUS CLAIM 
STORAGECLASS REASON AGE 
pvc -e98e9117 -3ed7-11e8-b61d-08002795cb26 1Gi RWO 
Delete Bound default/myclaim 
slow 1m 


e 可 以 将 slow 的 sc 设置 为 默认 ， 这 样 平 台 分 配 存储 的 时 候 可 以 自动 从 glusterfs 集 
群 分 配 pv 


# KUbect patch storageclass slow -p '("metadata": ("annotations 
":{"storageclass.kubernetes.io/is-default-class":"true"}}}' 
storageclass.storage.k8s.io "slow" patched 


# kubectl get sc 

NAME PROVISIONER AGE 
default fuseim.pri/ifs 1d 
slow (default) kubernetes.io/glusterfs 6h 


容量 限额 测试 


已 经 通过 Helm 部 署 的 一 个 mysql2 实例 ， 使 用 存储 2G， 信 息 查 看 如 下 : 


# helm list 


NAME REVISION UPDATED 

CHART NAMESPACE 

mysql2 1 Thu Apr 12 15:27:11 2018 
mysql-0.3.7 default 


& A PVCATePV > X 2G > mysql2-mysgql 


# kubectl get pvc 


STATUS 


DEPLOYED 


NAME STATUS VOLUME 

CAPACITY ACCESS MODES STORAGECLASS AGE 
mysq12-mysql Bound pvc -ea4ae3e0 -3e22-11e8-8bb 
6-08002795cb26 2Gi RWO slow 19h 


# kubectl get pv 


NAME CAPACITY ACCESS MOD 


ES RECLAIM POLICY STATUS CLAIM 
STORAGECLASS REASON AGE 


pvc-ea4ae3e0-3e22-11e8-8bb6-08002795cb26 26i RWO 
Delete Bound default/mysql2-mysql 
slow 19h 
4 A mysql 4 pod 
# kubectl get pod|grep mysgl2 
mysq12-mysql-56d64f5b77-j2v84 1/1 
Running 2 19h 
进入 mysql 所 在 容器 
# kubectl exec -it mysql2-mysql-56d64f5b77-j2v84 /bin/bash 


查看 挂 载 路 径 ， 查 看 挂 载 信息 


root@mysql2-mysql-56d64f5b77-j2v84:/#cd /var/lib/mysgl 
root@mysql2-mysql-56d64f5b77 - j2v84:/var/lib/mysql# 
root@mysql2-mysql-56d64f5b77-j2v84:/var/lib/mysql# df -h 


Filesystem Size Used A 

vail Use% Mounted on 

none 48G 9.2G 
37G 21% / 

tmpfs 1.56 0 
1.5G 0% /dev 

tmpfs 1.5G 0 
1.5G 0% /sys/fs/cgroup 

/dev/mapper/ubuntu- -1--vg-root 48G 9.26 
37G 21% /etc/hosts 

shm 64M 0 


64M 0% /dev/shm 
192.168.5.191:vol 2c2227ee65b64a0225aa9bce848a9925 2.0G 264M 
1.8G 13% /var/lib/mysql 


tmpfs 1.5G 12K 
1.5G 1% /run/secrets/kubernetes.io/serviceaccount 
tmpfs 1256 0 


1.5G 0% /sys/firmware 


使 用 dd 写 入 数据 ， 写 入 一 段 时 间 以 后 ， 空 间 满 了 ， 会 报错 (报错 信息 有 bug， 不 是 
报 空间 满 了 ， 而 是 报 文 件 系 统 只 读 ， 应 该 是 glusterfs 和 docker 配 合 的 问题 ) 


root@mysql2-mysql-56d64f5b77-j2v84:/var/lib/mysql# dd if-/dev/ze 
ro of=test.img bs=8M count=300 


dd: error writing 'test.img': Read-only file system 
dd: closing output file 'test.img': Input/output error 


查看 写 满 以 后 的 文件 大 小 


root@mysql2-mysql-56d64f5b77-j2v84:/var/lib/mysql# is -J 
total 2024662 


-rw-r----- 1 mysql mysql 56 Apr 12 07:27 auto.cnf 
-rw-r----- 1 mysql mysql 1329 Apr 12 07:27 ib buffer pool 
-rw-r----- 1 mysql mysql 50331648 Apr 12 12:05 ib logfileO 
-rw-r----- 1 mysql mysql 50331648 Apr 12 07:27 ib logfile1 
-rw-r----- 1 mysql mysql 79691776 Apr 12 12:05 ibdatai 
-rw-r----- 1 mysql mysql 12582912 Apr 12 12:05 ibtmp1 
drwxr-s--- 2 mysql mysql 8192 Apr 12 07:27 mysql 
drwxr-s--- 2 mysql mysql 8192 Apr 12 07:27 performance sch 
ema 

drwxr-s--- 2 mysql mysql 8192 Apr 12 07:27 sys 


-rw-r--r-- 1 root mysql 1880887296 Apr 13 02:47 test.img 


查看 挂 载 信 息 ( 挂 载 信息 显示 bug， 应 该 是 glusterfs 的 bug ) 


root@mysql2-mysql-56d64f5b77-j2v84:/var/lib/mysql# df 


Filesystem Size 
vail Use% Mounted on 

none 48G 
37G 21% / 

tmpfs 1.56 


1.5G 0% /dev 


tmpfs 1.56 


1.5G 0% /sys/fs/cgroup 


/dev/mapper/ubuntu--1--vg-root 48G 


37G 21% /etc/hosts 


shm 64M 


64M 0% /dev/shm 


192.168.5.191:vol_2c2227ee65b64a0225aa9bce848a9925 2.0G 


© 100% /var/lib/mysql 


tmpfs 1256 


1.5G 1% /run/secrets/kubernetes.io/serviceaccount 


tmpfs 1.56 


1.56 0% /sys/firmware 


查看 文件 夹 大 小 ， 为 2G 


25M ./mysql 


825K ./performance_schema 
496K ./SyS 
2.0G f 


如 上 说 明 glusterfs 的 限额 作用 是 起 效 的 ， 限 制 在 2G 的 空间 大 小 。 
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在 OpenShift 中 使 用 GlusterFS 做 持久 化 存储 


概述 


本 文 由 Daniel Messer (Technical Marketing Manager Storage @RedHat) 和 Keith 
Tenzer (Solutions Architect @RedHat) 共同 撰写 。 
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e Storage for Containers using NetApp ONTAP NAS - Part V 
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Gluster/¢ 4 Container-Ready Storage(CRS) 


在 本 文中 ， 我 们 将 介绍 容器 存储 的 首选 以 及 如 何 部 署 它 。Kusternet 和 OpenShift 支 
持 GlusterFS 已 经 有 一 段 时 间 了 。 GlusterFS 的 适用 性 很 好 ， 可 用 于 所 有 的 部 署 场 
X : 裸 机 、 上 庶 拟 机 、 内 部 部 署 和 公共 云 。 在 容器 中 运行 GlusterFS 的 新 特性 将 在 本 
系列 后 面 讨 论 。 


GlusterFS 是 一 个 分 布 式 文件 系统 ， 内 置 了 原生 协议 (GlusterFS) 和 各 种 其 他 协议 
(NFS > SMB? ...) 。 为 了 与 OpenShift 集 成 ， 节 点 将 通过 FUSE 使 用 原生 协议 ， 将 

GlusterFS 卷 挂 在 到 节点 本 身上 ， 然 后 将 它们 绑 定 到 目标 容器 中 。 OpenShift/ 

Kubernetes 具 有 实现 请 求 、 释 放 和 挂 载 、 印 载 GlusterFS 卷 的 原生 程序 。 


CRS 概 述 


在 存储 方面 ， 根 据 OpenShift/ Kubernetes 的 要 求 ， 还 有 一 个 额外 的 组 件 管理 集群 ， 
称 为 “heketi”。 这 实际 上 是 一 个 用 于 GlusterFS 的 REST API， 它 还 提供 CLI 版 本 。 

在 以 下 步骤 中 ， 我 们 将 在 3 个 GlusterFS 节 点 中 部 署 heketi， 使 用 它 来 部 署 GlusterFS 
存储 池 ， 将 其 连接 到 OpenShift， 并 使 用 它 来 通过 PersistentVolumeClaims 为 容器 配 
置 存储 。 我 们 将 总 共 部 署 4 台 虚拟 机 。 一 个 用 于 OpenShift (实验 室 设 置 ) ， 另 一 
个 用 于 GlusterFS。 


注意 : 您 的 系统 应 至 少 需要 有 四 核 CPU，16GB RAM 和 20 GB 可 用 磁盘 空间 。 


部 署 DpenShift 


首先 你 需要 先 部 署 OpenShift。 有 最 有 效率 的 方式 是 直接 在 虚拟 机 中 部 署 一 个 All-in- 
One 环 境 ， 部 署 指南 见 the "OpenShift Enterprise 3.4 all-in-one Lab Environment" 
article.。 


确保 你 的 OpenShift 虚 拟 机 可 以 解析 外 部 域名 。 编 辑 /etc/dnsmasq.conf 文件 ， 
增加 下 面 的 Google DNS : 


server=8.8.8.8 


重启 : 


# systemctl restart dnsmasq 
# ping -c1 google.com 


#8 #Gluster 


GlusterFS 至 少 需要 有 以 下 配置 的 3 台 庶 拟 机 : 


e RHEL 7.3 

e 2 CPUS 

e 2 GB 内 存 

e 30 GB 磁盘 存储 给 操作 系统 

e 10 GB 磁盘 存储 给 GlusterFS bricks 


修改 /etc/hosts 文 件 ， 定 义 三 台 虚 拟 机 的 主机 名 。 


例如 (主机 名 可 以 根据 你 自己 的 环境 自由 调整 ) 


# cat /etc/hosts 


127.0.0.1 localhost localhost.localdomain localhost4 localh 
ost4.localdomain4 
vq localhost localhost.localdomain localhost6 localh 


ost6.localdomain6 

172.16.99.144 ocp-master.lab ocp-master 
172.16.128.7 crs-node1.lab crs-nodet 
172.16.128.8 crs-node2.lab crs-node2 
172.16.128.9 crs-node3.lab crs-node3 


在 3 台 GlusterFS 虚 拟 机 上 都 执行 以 下 步骤 : 


# subscription-manager repos --disable="*" 
# subscription-manager repos --enable=rhel-7-server-rpms 


如 果 你 已 经 订阅 了 GlusterFS 那 么 可 以 直接 使 用 ， 开 尼 rh-gluster-3-for-rhel- 
7-server-rpms 的 yum 源 。 


如 果 你 没有 的 话 ， 那 么 可 以 通过 EPEL 使 用 非 官 方 支持 的 GlusterFS 的 社区 源 。 


# yum -y install http://dl.fedoraproject.org/pub/epel/epel-relea 
se-latest-7.noarch.rpm 

# rpm --import http://dl.fedoraproject.org/pub/epel/RPM-GPG-KEY- 
EPEL - 7 


在 /etc/yum.repos.d/ 目录 下 创建 glusterfs-3.10.repo 文件 : 


[glusterfs-3.10] 

name=glusterfs-3.10 

description="GlusterFS 3.10 Community Version" 
baseurl-https://buildlogs.centos.org/centos/7/storage/x86 64/glu 
ster-3.10/ 

gpgcheck=0 

enabled=1 


验证 源 已 经 被 激活 。 
# yum repolist 


现在 可 以 开始 安装 GlusterFS 了 。 


# yum -y install glusterfs-server 


需要 为 GlusterFS peers 打 开 几 个 基本 TCP 端 口 ， 以 便 与 OpenShift 进 行 通信 并 提供 
存储 


# firewall-cmd --add-port=24007-24008/tcp --add-port=49152-49664 
/tcp --add-port=2222/tcp 
# firewall-cmd --runtime-to-permanent 


现在 我 们 可 以 启动 GlusterFS 的 daemon 进 程 了 : 


# systemctl enable glusterd 
# systemctl start glusterd 


完成 。GlusterFS 已 经 启动 并 正在 运行 。 其 他 配置 将 通过 heketi 完 成 。 


在 GlusterFS 的 一 人 台 虚 拟 机 上 安装 heketi 


[root@crs-node1 ~]# yum -y install heketi heketi-client 


更 新 EPEL 


I iX 44 Red Hat Gluster Storage 订 阅 的 话 ， 你 可 以 从 EPEL 中 获取 heketi。 在 
写本 文 时 ，2016 年 10 月 那 时候 还 是 3.0.0-1.el7 版 本 ， 它 不 适用 于 OpenShift 3.4 » 
你 将 需要 更 新 到 更 新 的 版 本 : 


[root@crs-node1 ~]# yum -y install wget 

[root@crs-node1 ~]# wget https://github.com/heketi/heketi/releas 
es/download/v4.0.0/heketi-v4.0.0.linux.amd64, tar.gz 
[rootücrs-nodei ~]# tar -xzf heketi-v4.0.0.linux.amd64. tar.gz 
[root@crs-node1 ~]# systemctl stop heketi 

[root@crs-node1 ~]# cp heketi/heketi* /usr/bin/ 

[root@crs-node1 ~]# chown heketi:heketi /usr/bin/heketi* 


在 /etc/systemd/system/heketi.service 中 创建 v4 版 本 的 heketi 二 进 制 文件 的 
更 新 语 法 文件 : . 


在 OpenShift 中 使 用 GlusterFS 做 持久 化 存储 


[Unit ] 
Description=Heketi Server 


[Service] 

Type=simple 
WorkingDirectory=/var/lib/heketi 
EnvironmentFile=-/etc/heketi/heketi. json 


User=heketi 
ExecStart=/usr/bin/heketi --config=/etc/heketi/heketi. json 


Restart=on-failure 
StandardOutput=syslog 
StandardError=syslog 


[Install] 
WantedBy=multi-user.target 


[rootücrs-nodei ~]# systemctl daemon-reload 
[root@crs-node1 ~]# systemctl start heketi 


Heketi 使 用 SSH 来 配置 GlusterFS 的 所 有 节点 。 创 建 SSH 密 钥 对 ， 将 公 角 拷贝 到 所 
有 3 个 节点 上 (包括 你 登陆 的 第 一 个 节点 ) 


[root@crs-node1 ~]# ssh-keygen -f /etc/heketi/heketi key -t rsa 
-N TT! 
[root@crs-node1 ~]# ssh-copy-id -i /etc/heketi/heketi key.pub ro 


ot@crs-node1.lab 
[root@crs-node1 ~]# ssh-copy-id -i /etc/heketi/heketi key.pub ro 


ot@crs-node2.lab 
[root@crs-node1 ~]# ssh-copy-id -i /etc/heketi/heketi key.pub ro 


ot@crs-node3.lab 
[root@crs-node1 ~]# chown heketi:heketi /etc/heketi/heketi key* 


剩 下 唯一 要 做 的 事情 就 是 配置 heketi 来 使 用 SSH ° À 
辑 /etc/heketi/heketi.json 文件 使 它 看 起 来 像 下 面 这 个 样子 (改变 的 部 分 突出 
显示 下 划 线 ) 


" port comment":"Heketi Server Port Number", 

"port" : "8080", 

" use auth":"Enable JWT authorization. Please enable for depl 
oyment", 

"use_auth":false, 

"_jwt":"Private keys for access", 

"jwt" :{ 

" admin":"Admin has access to all APIs", 


853 


在 OpenShift 中 使 用 GlusterFS 做 持久 化 存储 


"admin": { 
"key": "My Secret" 
tr 
" user":"User only has access to /volumes endpoint", 
"user": { 
"key": "My Secret" 
} 


tr 
" glusterfs comment":"GlusterFS Configuration", 
"glusterfs":( 
" executor comment":[ 
"Execute plugin. Possible choices: mock, ssh", 
"mock: This setting is used for testing and development 


" It will not send commands to any node.", 

"ssh: This setting will notify Heketi to ssh to the nod 
ps." 

" It will need the values in sshexec to be configured.", 


"kubernetes: Communicate with GlusterFS containers over" 


" Kubernetes exec api." 
], 
"executor":"ssh", 
" sshexec comment":"SSH username and private key file info 
rmation", 
"sshexec": { 
"keyfile":"/etc/heketi/heketi_key", 
"user": "root", 
"port" E EM. 
"fstab":"/erc/fstrab" 
tr 
" kubeexec comment":"Kubernetes configuration", 
"kubeexec": { 
"host": "https://kubernetes.host :8443", 
"cert": "/path/to/crt.file", 
"insecure":false, 
"user": "kubernetes username", 
"password": "password for kubernetes user", 
"namespace":"OpenShift project or Kubernetes namespace", 


"fstab":"Optional: Specify fstab file on node. Default 
is /etc/fstab" 
tr 
" db comment":"patabase file name", 
"db":"/var/lib/heketi/heketi.db", 
"_loglevel_comment": [ 
"Set log level. Choices are:", 
" none, critical, error, warning, info, debug", 
"Default is warning" 


1, 
"loglevel": "debug" 
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完成 。heketi 将 监听 8080 端 口 ， 我 们 来 确认 下 防火 墙 规则 允许 它 监 听 该 端口 : 


# firewall-cmd --add-port=8080/tcp 
# firewall-cmd --runtime-to-permanent 


重启 heketi : 


# systemctl enable heketi 
# systemctl restart heketi 


测试 它 是 否 在 运行 : 


# curl http://crs-node1.lab: 8080/hello 
Hello from Heketi 


很 好 。heketi 上 场 的 时 候 到 了 。 我 们 将 使 用 它 来 配置 我 们 的 GlusterFS 存 储 池 。 该 
软件 已 经 在 我 们 所 有 的 虚拟 机 上 运行 ， 但 并 未 被 配置 。 要 将 其 改造 为 满足 我 们 需求 


的 存储 系统 ， 需 要 在 拓扑 文件 中 描述 我 们 所 需 的 GlusterFS 存 储 池 ， 如 下 所 示 : 


# vi topology.json 
{ 


"clusters": [ 
"nodes": [ 


"node": { 
"hostnames": { 
"manage": [ 
"crs-node1.lab" 
l; 
"storage": [ 
ULI2.10.129,.7" 


] 

t 

"Zone": 1 
b 
"devices": [ 

"/gev/sdb" 
] 

ty 


{ 


Orr 


"node": { 
"hostnames": { 
"manage": [ 
"crs-node2.lab" 
l; 
"storage": [ 
"172,16.128.8" 


"devices": [ 
"/dev/sdb" 


tr 
{ 

"node": { 
"hostnames": { 
"manage": [ 

"crs-node3.lab" 


]; 
"storage": [ 
"172.10.129.9" 


"devices": [ 
"/dev/sdb" 


该 文件 格式 比较 简单 ， 基 本 上 是 告诉 heketi 要 创建 一 个 3 节点 的 集群 ， 其 中 每 个 节点 
包含 的 配置 有 FQDN，IP 地 址 以 及 至 少 一 个 将 用 作 GlusterFS 块 的 备用 块 设 备 。 


现在 将 该 文件 发 送 给 heketi : 


# export HEKETI_CLI_SERVER=http://crs-node1.lab: 8080 
# heketi-cli topology load --json=topology.json 

Creating cluster ... ID: 78cdb57aa362f5284bc95b2549bc7e7d 
Creating node crs-node1.lab ... ID: ffd7671c0083d88aeda9fdi1cb40 
b339b 

Adding device /dev/sdb ... OK 

Creating node crs-node2.lab ... ID: 8220975c0a4479792e684584153 
050a9 

Adding device /dev/sdb ... OK 

Creating node crs-node3.lab ... ID: b94f14c4dbd8850f6ac589ac3b3 
9cc8e 

Adding device /dev/sdb ... OK 


现在 heketi 已 经 配置 了 3 个 节点 的 GlusterFS 存 储 池 。 很 简单 ! 你 现在 可 以 看 到 3 个 虚 
拟 机 都 已 经 成 功 构成 了 GlusterFS 中 的 可 信 存 储 池 (Trusted Stroage Pool) 。 


[root@crs-node1 ~]# gluster peer status 
Number of Peers: 2 


Hostname: crs-node2. lab 

Uuid: 93b34946-9571-46a8-983c-c9f128557c0e 
State: Peer in Cluster (Connected) 

Other names: 

crs-node2.lab 


Hostname: 172.16.128.9 
Uuid: e3cif9b0-be97-42e5-beda-f70fc05f47ea 
State: Peer in Cluster (Connected) 


现在 回 到 OpenShift ! 


将 Gluster 与 OpenShift 集 成 


为 了 集成 OpenShift， 需 要 两 样 东 西 : 一 个 动态 的 Kubernetes Storage Provisioner 
fe — ^-StorageClass 。 Provisioner 在 OpenShift 中 开 箱 即 用 。 实际 上 关键 的 是 如 何 
将 存储 挂 载 到 容器 上 。 StorageClass 是 OpenShift 中 的 用 户 可 以 用 来 实现 的 
PersistentVolumeClaims 的 实体 ， 它 反 过 来 能 够 触发 一 个 Provisioner 实 现实 际 的 配 
置 ， 并 将 结果 表示 为 Kubernetes PersistentVolume (PV) 。 


就 像 OpenShift 中 的 其 他 组 件 一 样 ，StorageClass 也 简单 的 用 YAML 文 件 定 义 : 


# cat crs-storageclass.yaml 
kind: StorageClass 
apiVersion: storage.k8s.io/vibetai 
metadata: 
name: container-ready-storage 
annotations: 
storageclass.beta.kubernetes.io/is-default-class: "true" 
provisioner: kubernetes.io/glusterfs 
parameters: 
resturl: "http://crs-node1.1ab:8080" 
restauthenabled: "false" 


我 们 的 provisioner 是 kubernetes.io/glusterfs， 将 它 指向 我 们 的 heketi 实 例 。 我 们 将 
类 命名 为 “container-ready-storage”， 同 时 使 其 成 为 所 有 没有 显示 指定 StorageClass 
的 PersistentVolumeClaim 的 默认 StorageClass。 


为 你 的 GlusterFS 池 创建 StorageClass : 


# oc create -f crs-storageclass.yaml 


4 OpenShift ¥ i /#] Gluster 


我 们 来 看 下 如 何在 OpenShift 中 使 用 GlusterFS。 首 先 在 OpenShift 庶 拟 机 中 创建 一 
测试 项 目 。 


# oc new-project crs-storage --display-name="Container-Ready Sto 
rage" 


这 会 向 Kubernetes/OpenShift 发 出 storage 请 求 ， 请 求 一 个 
AAS 
量 和 应 该 提供 哪 种 访问 模式 ( 非 共享 ， 共 享 ， 只 读 ) 。 它 通 常 是 应 用 程序 模板 的 一 
部 分 ， 但 我 们 只 需 创 rere 


# cat crs-claim.yaml 
apiVersion: vi 
kind: PersistentVolumeClaim 
metadata: 

name: my-crs-storage 

namespace: crs-storage 
spec: 

accessModes: 

- ReadwriteOnce 

resources: 

requests: 

storage: 1Gi 


发 送 该 请 求 : 
# oc create -f crs-claim.yaml 
观察 在 OpenShfit 中 ，PVC 正 在 以 动态 创建 volume 的 方式 实现 : 


# OC get pvc 


NAME STATUS VOLUME 

CAPACITY ACCESSMODES AGE 
my-crs-storage Bound pvc -41ad5adb-107c-11e7 -afae-000c2949c 
Ce7 1Gi RWO 58s 


KIT | 你 现在 可 以 在 OpenShift 中 使 用 存储 容量 ， 而 不 需要 直接 与 存储 系统 进行 
任何 交互 。 我 们 来 看 看 创建 的 volume : 


# oc get pv/pvc-41adb5adb-107c-11e7-afae-000c2949cce7 


Name: pvc-41ad5adb-107c-11e7-afae-000c2949cce7 
Labels: 
StorageClass: container-ready-storage 
Status: Bound 
Claim: crs-storage/my-crs-storage 
Reclaim Policy: Delete 
Access Modes: RWO 
Capacity: 16i 
Message: 
Source: 
Type: Glusterfs (a Glusterfs mount on the host that s 
hares a pod's lifetime) 
EndpointsName: gluster-dynamic-my-crs-storage 
Path: vol 85e444ee3bc154de084976a9aef16025 


ReadOnly: false 


What happened in the background was that when the PVC reached the system, 
our default StorageClass reached out to the GlusterFS Provisioner with the 
volume specs from the PVC. The provisioner in turn communicates with our heketi 
instance which facilitates the creation of the GlusterFS volume, which we can 
trace in it’s log messages: 


该 volume 是 根据 PVC 中 的 定义 特别 创建 的 。 在 PVC 中 ， 我 们 没有 明确 指定 要 使 用 
哪个 StorageClass， 因 为 heketi 的 GlusterFS StorageClass 已 经 被 定义 为 系统 范 
的 默认 值 。 


在 后 合 发 生 的 情况 是 ， 当 PVC 到 达 系 统 时 ， 上 默认 的 StorageClass 请 求 具有 该 PVC 中 
volume 声 明 规 格 的 GlusterFS Provisioner ° Provisioner 又 与 我 们 的 heketi 实 例 通 
信 ， 这 有 助 于 创建 GlusterFS volume， 我 们 可 以 在 其 日 志 消 息 中 追踪 : 


[root@crs-node1 ~]# journalctl -1 -u heketi.service 


Mar 24 11:25:52 crs-node1.lab heketi[2598]: [heketi] DEBUG 2017/ 
03/24 11:25:52 /src/github.com/heketi/heketi/apps/glusterfs/volu 
me_entry.go:298: Volume to be created on cluster e 

Mar 24 11:25:52 crs-node1.lab heketi[2598]: [heketi] INFO 2017/0 
3/24 11:25:52 Creating brick 9e791b1daai2af783c9195941fe63103 
Mar 24 11:25:52 crs-node1.lab heketi[2598]: [heketi] INFO 2017/0 
3/24 11:25:52 Creating brick 3e06af2f855bef521a95ada91680d14b 
Mar 24 11:25:52 crs-node1.lab heketi[2598]: [heketi] INFO 2017/0 
3/24 11:25:52 Creating brick e4daa240f1359071e3f7ea22618cfbab 


Mar 24 11:25:52 crs-node1.lab heketi[2598]: [sshexec] INFO 2017/ 
03/24 11:25:52 Creating volume vol 85e444ee3bc154de084976a9aef16 
025 replica 3 


Mar 24 11:25:53 crs-node1.lab heketi[2598]: Result: volume creat 
e: vol 85e444ee3bc154de084976a9aef16025: success: please start t 
he volume to access data 


Mar 24 11:25:55 crs-node1.lab heketi[2598]: Result: volume start 
: vol 85e444ee3bc154de084976a9aef16025: success 


Mar 24 11:25:55 crs-node1.lab heketi[2598]: [asynchttp] INFO 201 
7/03/24 11:25:55 Completed job c3d6c4f9fc74796f4a5262647dc790fe 
in 3.176522702s 


成 功 ! 大 约 用 了 3 秒 钟 ，GlusterFS 池 就 配置 完成 了 ， 并 配置 了 一 个 volume。 Rik 
值 是 replica 3， 这 意味 着 Pa | 到 3 个 不 同 节点 的 3 个 块 上 (用 GlusterFS 作 为 
EmA) 。 该 过 程 是 通过 Heketi 在 OpenShift 进 行 编排 的 。 


你 也 可 以 从 GlusterFS 的 角度 看 到 有 关 volume 的 信息 : 


[root@crs-nodei ~]# gluster volume list 

vol 85e444ee3bc154de084976a9aef16025 

[root@crs-node1 ~]# gluster volume info vol 85e444ee3bci154de0849 
76a9aef16025 


Volume Name: vol 85e444ee3bc154de084976a9aef16025 

Type: Replicate 

Volume ID: a32168c8-858e-472a-b145-08c20192082b 

Status: Started 

Snapshot Count: 0 

Number of Bricks: 1x 3 = 3 

Transport-type: tcp 

Bricks: 

Brick1: 172.16.128.8:/var/lib/heketi/mounts/vg_147b43f6f6903be8b 
23209903b7172ae/brick 9e791b1daa12af783c9195941fe63103/brick 
Brick2: 172.16.128.9:/var/lib/heketi/mounts/vg 72c0f520b0c57d807 
be21e9c90312f85/brick 3e06af2f855bef521a95ada91680d14b/brick 
Brick3: 172.16.128.7:/var/lib/heketi/mounts/vg 67314f879686de975 
f9b8936ae43c5c5/brick e4daa240f1359071e3f7ea22618cfbab/brick 
Options Reconfigured: 

transport.address-family: inet 

nfs.disable: on 


请 注意 ，GlusterFS 中 的 卷 名 称 如何 对 应 于 OpenShift 中 Kubernetes Persistent 
Volume 的 “路 径 ”。 


或 者 ， 你 也 可 以 使 用 OpenShift UI 来 配置 存储 ， 这 样 可 以 很 方便 地 在 系统 中 的 所 有 
已 知 的 StorageClasses 中 进行 选择 : 


Container-Ready Storage Storage Create Storage 


Create Storage 


Create a request for an administrator-defined storage asset by specifying size and permissions for a best fit. 


* Storage Classes 


Storage classes are set by the administrator to define types of storage the users can select. 
Learn more (7 


© container-ready-storage 
Type: | Zone: 


No Storage Class 


No storage class will be assigned unless a default class has been assigned by the system administrator. 


* Name 
my-crs-storage 


A unique name for the storage claim within the project. 
* Access Mode 


Q Single User (RWO) Shared Access (RWX) © Read Only (ROX) 


Permissions to the mounted volume. 


* Size 


| 


Desired storage capacity. 


Use label selectors to request storage 


图 片 - 创建 存储 
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让 我 们 做 点 更 有 趣 的 事情 ， 在 OpenShift 中 运行 工作 负载 。 


在 仍 运行 着 crs-storage 项 目的 OpenShift 虚 拟 机 中 执行 : 


# oc get templates -n openshift 


你 应 该 可 以 看 到 一 个 应 用 程序 和 数据 库 模板 列表 ， 这 个 列表 将 方便 你 更 轻松 的 使 用 
OpenShift 来 部 署 你 的 应 用 程序 项 目 。 


我 们 将 使 用 MySQL 来 演示 如 何在 OpenShift 上 部 署 具 有 持久 化 和 弹性 存储 的 有 状态 
应 用 程序 。 Mysql-persistent 模 板 包含 一 个 用 于 MySQL 数 据 库 目录 的 1G 空 间 的 
PVC。 为 了 演示 目的 ， 可 以 直接 使 用 默认 值 。 


# oc process mysql-persistent -n openshift | oc create -f - 


# oc get pods 
NAME READY STATUS RESTARTS AGE 
mysql-1-h4afb 1/1 Running 0 2m 


好 了 。 我 们 已 经 使 用 这 个 模板 创建 了 一 个 service，secrets、PVC 和 pod。 我 们 来 使 
用 它 〈 你 的 pod 名 字 将 跟 我 的 不 同 ) 


# oc rsh mysql-1-h4afb 
你 已 经 成 功 的 将 它 挂 载 到 MySQL 的 pod 上 。 我 们 连接 一 下 数据 库 试 试 : 


sh-4.2$ mysql -u $MYSQL USER -p$MYSQL PASSWORD -h $HOSTNAME $MYS 
QL DATABASE 


这 点 很 方便 ， 所 有 重要 的 配置 ， 如 MySQL 和 凭据 ， 数 据 库 名 称 等 都 是 pod 模 板 中 的 环 
境 变 量 的 一 部 分 ， 因 此 可 以 在 pod 中 作为 shell 的 环境 变量 。 我 们 来 创建 一 些 数据 : 


mysql> show databases; 


ee eed + 
| Database | 
Riesen coc Seb eS ae + 
| information_schema | 
| sampledb | 
usce sucesos ds ems + 


2 rows in set (0.02 sec) 


mysql> \u sampledb 
Database changed 
mysql> CREATE TABLE IF NOT EXISTS equipment ( 


-> equip_id int(5) NOT NULL AUTO_INCREMENT, 
-> type varchar(50) DEFAULT NULL, 

-> install_date DATE DEFAULT NULL, 

-> color varchar(20) DEFAULT NULL, 

-> working bool DEFAULT NULL, 

-> location varchar(250) DEFAULT NULL, 

-> PRIMARY KEY(equip_id) 

TT ); 


Query OK, © rows affected (0.13 sec) 


mysql» INSERT INTO equipment (type, install date, color, working 
, location) 

-» VALUES 

-» ("Slide", Now(), "blue", 1, "Southwest Corner"); 
Query OK, 1 row affected, 1 warning (0.01 sec) 


mysql» SELECT * FROM equipment; 


[esie s Bota SP iar attr Sp esha ee Spee tree ig RSEN ON de 
—€— M + 
| equip id | type | install date | color | working | location 

| 
于 qp Ies Ret gk RU nu facie die RE Ferno eai 
Jogas + 
| 1 | Slide | 2017-03-24 | blue | 1 | Southwest 
Corner | 
uetus pe ue : PEE Shit a eee es Stes us Bond piu Ee 
ee ari + 


1 row in set (0.00 sec) 


很 好 ， 数 据 库 运行 正常 。 


你 想 看 下 数据 存储 在 哪里 吗 ? 很 简单 ! 查看 刚 使 用 模板 创建 的 mysql volume : 


# oc get pvc/mysgl 
NAME STATUS VOLUME C 


APACITY ACCESSMODES AGE 
mysql Bound pvc-a678b583-1082-11e7-afae-000c2949cce7 1 
Gi RWO 11m 
# oc describe pv/pvc-a678b583-1082-11e7-afae-000c2949cce7 
Name: pvc-a678b583-1082-11e7-afae-000c2949cce7 
Labels: 
StorageClass: container-ready-storage 
Status: Bound 
Claim: crs-storage/mysql 
Reclaim Policy: Delete 
Access Modes: RWO 
Capacity: 16i 
Message: 
Source: 
Type: Glusterfs (a Glusterfs mount on the host that s 
hares a pod's lifetime) 
EndpointsName: gluster-dynamic-mysql 
Path: vol 6299fc74eee513119dafd43f8a438db1 
ReadOnly: false 


GlusterFS “volume @ F x vol 6299fc74eee513119dafd43f8a438db1 » EZ 4 ay 
GlusterFS J£ 4A dU P » HA: 


4 gluster volume info vol 6299fc74eee513119dafd43f8a438db 


Volume Name: vol 6299fc74eee513119dafd43f8a438db1 

Type: Replicate 

Volume ID: 4115918f -28f7-4d4a-b3f5-4b9afe5b391F 

Status: Started 

Snapshot Count: 0 

Number of Bricks: 1x 3 = 3 

Transport-type: tcp 

Bricks: 

Brick1: 172.16.128.7:/var/lib/heketi/mounts/vg_67314f879686de975 
f9b8936ae43c5c5/brick f264a47aa32be5d595f83477572becf8/brick 
Brick2: 172.16.128.8:/var/lib/heketi/mounts/vg 147b43f6f6903be8b 
23209903b7172ae/brick f5731fe7175cbe6e6567e013c2591343/brick 
Brick3: 172.16.128.9:/var/lib/heketi/mounts/vg 72c0f520b0c57d807 
be21e9c90312f85/brick aceadd804a6a467cd81cd1404841bbfi1/brick 
Options Reconfigured: 

transport.address-family: inet 

nfs.disable: on 


你 可 以 看 到 数据 是 如 何 被 复制 到 3 个 GlusterFS 块 的 。 我 们 从 中 挑 一 个 (最 好 挑选 你 
刚 登 陆 的 那 台 虚拟 机 并 查看 目录 ) 


t 11 /var/lib/heketi/mounts/vg 67314f879686de975f9b8936ae43c5c5/ 
brick f264a47aa32be5d595f83477572becf8/brick 
total 180300 


-rw-r----- . 2 1000070000 2001 56 Mar 24 12:11 auto.cnf 
-rw------- . 2 1000070000 2001 1676 Mar 24 12:11 ca-key.pem 
-rw-r--r--. 2 1000070000 2001 1075 Mar 24 12:11 ca.pem 
-rw-r--r--. 2 1000070000 2001 1079 Mar 24 12:12 client-cert. 
pem 

-rw------- . 2 1000070000 2001 1680 Mar 24 12:12 client-key.p 
em 

-rw-r----- . 2 1000070000 2001 352 Mar 24 12:12 ib buffer po 
ol 

-rw-r----- . 2 1000070000 2001 12582912 Mar 24 12:20 ibdatai 
-rw-r----- . 2 1000070000 2001 79691776 Mar 24 12:20 ib logfileO 
-rw-r----- . 2 1000070000 2001 79691776 Mar 24 12:11 ib logfilei 
-rw-r----- . 2 1000070000 2001 12582912 Mar 24 12:12 ibtmp1 
drwxr-s---. 2 1000070000 2001 8192 Mar 24 12:12 mysql 
-rw-r----- . 2 1000070000 2001 2 Mar 24 12:12 mysql-1-h4af 
b.pid 

drwxr-s---. 2 1000070000 2001 8192 Mar 24 12:12 performance 
schema 

-DW------- . 2 1000070000 2001 1676 Mar 24 12:12 private key. 
pem 

-rw-r--r--. 2 1000070000 2001 452 Mar 24 12:12 public key.p 
em 

drwxr-s---. 2 1000070000 2001 62 Mar 24 12:20 sampledb 
-rw-r--r--. 2 1000070000 2001 1079 Mar 24 12:11 server-cert. 
pem 

-rw------- . 2 1000070000 2001 1676 Mar 24 12:11 server-key.p 
em 

drwxr-s---. 2 1000070000 2001 8192 Mar 24 12:12 sys 


你 可 以 在 这 里 看 到 MySQL 数 据 库 目录 。 它 使 用 GlusterFS 作 为 后 端 存 储 ， 并 作为 绑 
定 挂 载 给 MySQL 容 器 使 用 。 如 果 你 检查 OpenShift VM 上 的 mount 表 ， 你 将 会 看 到 
GlusterFS 的 mount 。 


GK 


在 这 里 我 们 是 在 DpenShift 之 外 创建 了 一 个 简单 但 功能 强大 的 GlusterFS 存 储 池 。 该 
池 可 以 独立 于 应 用 程序 扩展 和 收缩 。 eee 个 生命 周期 由 一 个 简单 的 称 为 heketi 
的 前 端 管 理 ， 你 只 需要 在 部 署 增长 时 进行 手动 干预 。 对 于 日 常 配置 操作 ， 使 用 它 的 
API 与 OpenShifts 动 态 配 置 器 交互 ， 无 需 开 发 人 员 直 接 与 基础 架构 团队 进行 交互 。 


0 这 就 是 我 们 如 何 将 存储 带 入 DevOps 世 界 - 无 痛苦 ， 并 在 OpenShift PaaS 系 统 的 开 
发 人 员工 具 中 直接 提供 。 


GlusterFS 和 OpenShift 可 跨越 所 有 环境 : 裸 机 ， 庶 拟 机 ， 私 有 和 公共 云 (Azure ’ 
Google Cloud > AWS ...) ， 确 保 应 用 程序 可 移植 性 ， 并 避免 云 供 应 商 锁定 。 


祝 你 愉快 在 容器 中 使 用 GlusterFS ! 
(c) 2017 Keith Tenzer 


原文 链接 : https://keithtenzer.com/201 7/03/24/storage-for-containers-using- 
gluster-part-ii/ 
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Ceph 的 简要 介绍 


本 文 参考 翻译 自 这 篇 文章 的 部 分 内 容 。 


Ceph 是 一 个 开源 的 分 布 式 对 象 ， 块 和 文件 存储 。 该 项 目 诞 生 于 2003 年 ， 是 塞 奇 : 韦 
伊 的 博士 论文 的 结果 ， 然 后 在 2006 年 在 LGPL 2.1 许 可 证 发 布 。Ceph 已 经 与 Linux 内 
核 KVM 集 成 ， 并 且 默 认 包含 在 许多 GNU / Linux 发 行 版 中 。 


介绍 


当前 的 工作 负 -o X36, 35 XR Ee] MBG AK (RoR LH) ，Ceph 支 
持 所 有 这 些 方法 。 它 旨 在 具有 可 扩展 性 ， 并 且 没 有 单 点 故障 。 它 是 一 款 开源 软件 ， 
A 支行 。 


RADOS (可 靠 的 自动 分 布 式 对 象 存储 ) 是 Ceph 的 核心 组 件 。RADOS 对 象 和 当今 
流行 的 对 象 之 间 存 在 着 重要 的 区 别 ， 例 如 Amazon S3 > OpenStack Swift 或 Ceph 的 
RADOS 对 象 网 关 提 供 的 对 象 。 从 2005 年 到 2010 年 ， 对 象 存 储 设 备 〈OSD ) 成 为 一 
个 流行 的 概念 。 这 些 OSD 提 供 了 强大 的 一 致 性 ， 提 供 不 同 的 接口 ， 并 且 每 个 对 象 通 
驻 留 在 单个 设备 上 。 
在 RADOS 中 有 几 种 操作 对 象 的 方法 : 
e 在 用 C，C ++，Java，PHP 和 Python 编写 的 应 用 程序 中 使 用 客户 端 库 
(librados ) 


e 使 用 命令 行 工 具 'rados' 
e 使 用 与 S3 (Amazon) 和 Swift (OpenStack) 兼容 的 现 有 API 


RADOS 是 一 个 由 Ceph 节 点 组 成 的 集群 。 有 两 种 类 型 的 节点 : 


e Ceph 存 储 设 备 节点 
e Ceph 监 控 节 点 


每 个 Ceph 存 储 设 备 节点 运行 一 个 或 多 个 Ceph OSD 守 护 进程 ， 每 个 磁盘 设备 一 个 。 
OSD% — ^-Linux3t 42 S Add ) ， 可 处 理 与 其 分 配 的 磁盘 (HDD 或 SSD) 相关 
的 所 有 操作 。 所 述 OSD 守 护 程序 访问 本 地 文件 系统 来 存储 数据 和 元 数据 ， 而 不 是 直 


接 与 磁盘 通信 。Ceph 常 用 的 文件 系统 是 XFS，btrfs 和 ext4。 每 个 ODSD 还 需要 一 个 日 
志 ， 用 于 对 RADOS 对 象 进 行 原子 更 新 。 日 志 可 能 驻 留 在 单独 的 磁盘 上 (通常 是 
SSD 以 提高 性 能 ) ， 但 同一 个 磁盘 可 以 被 同一 节点 上 的 多 个 OSD 使 用 。 


该 Ceph 的 监控 节点 上 运行 的 单个 Ceph 的 监控 守护 。Ceph Monitor 守 护 程序 维护 集 
群 映射 的 主 副本 。 虽 然 Ceph 集 群 可 以 与 单个 监控 节点 一 起 工作 ， 但 需要 更 多 设备 来 
确保 高 可 用 性 。 建 议 使 用 三 个 或 更 多 Ceph Monitor 节 点 ， 因 为 它们 使 用 法 定数 量 来 
维护 集群 映射 。 需 要 大 多 数 Monitor 来 确认 仲裁 数 ， 因 此 建议 使 用 奇数 个 Monitor 。 
例如 ，3 个 或 4 个 Monitor 都 可 以 防止 单个 故障 ， 而 5 个 Monitor 可 以 防止 两 个 故障 。 


Ceph OSD 守 护 进 程 和 Ceph 客 户 端 可 以 感知 群集 ， 因 此 每 个 Ceph OSD 守 护 进 程 都 
可 以 直接 与 其 他 Ceph OSD ie it ££ 40 Ceph Ma 2 85 3t (13848 © WEF > Ceph P 3s 
可 直接 与 Ceph OSD 守 护 进程 通信 以 读 取 和 写 入 数据 。 


Ceph 对 象 网 关 守 护 进 程 (radosgw) 提供 了 两 个 API : 


e API 与 Amazon $3 RESTful AP 的 子 集 兼容 
e API 与 OpenStack Swift API 的 子 集 兼 容 


如 果 RADOS 和 radosgw 为 客户 提供 对 象 存 储 服务 ， 那 么 Ceph 如 何 被 用 作 块 和 文件 
存储 ? 


Ceph 中 的 分 布 式 块 存储 (Ceph RDB) 实现 为 对 象 存储 顶部 的 薄 层 。Ceph RADOS 
块 设备 (RBD) 存储 分 布 在 群集 中 多 个 Ceph OSD 上 的 数据 。RBD 利 用 RADOS 功 
能 ， 如 快照 ， 复 制 和 一 致 性 。RBD 使 用 Linux 内 核 模 块 或 librbd 库 与 RADOS 通 信 
此 外 ，KVM 管 理 程序 可 以 利用 librbd 允 许 庶 拟 机 访问 Ceph 卷 。 


Ceph 文 件 系统 (CephFS) 是 一 个 符合 POSIX 的 文件 系统 ， 使 用 Ceph 集 群 来 存储 
其 数据 。 所 述 Ceph 的 文件 系统 要 求 Ceph 的 集群 中 的 至 少 一 个 Ceph 的 元 数据 服务 器 
(MDS) 。MDS 处 理 所 有 文件 操作 ， 例 如 文件 和 目录 列表 ， 属 性 ， 所 有 权 等 。 
MDS 利 用 RADOS 对 象 来 存储 文件 系统 数据 和 属性 。 它 可 以 水 平 扩 展 ， 因 此 您 可 以 
将 更 多 的 Ceph 元 数据 服务 器 添加 到 您 的 群集 中 ， 以 支持 更 多 的 文件 系统 操作 客户 


Tm o 


Kubernetes 2» Ceph 


Kubernetes X 44 Ceph ay 2k & fă (Ceph RDB) 和 文件 存储 (CephFS) 作为 
Kubernetes $5 44 A. 7% fit & 3% ° Kubernetes 4 #*Ceph RDB internal E , 
可 以 配置 动态 提供 ， 如 果 要 使 用 CephFS 作 为 动态 存储 提供 ， 需 要 安装 外 置 


provisioner ° 


与 Ceph 相 关 的 Kubernetes StorageClass 的 官方 文档 介绍 


Volume Plugin Internal Provisioner Config Example 
AWSElasticBlockStore V AWS 
AzureFile V Azure File 
AzureDisk V Azure Disk 
CephFS - - 

Cinder V OpenStack Cinder 
FC - - 
FlexVolume - - 
Flocker / 2 
GCEPersistentDisk V GCE 
Glusterfs V Glusterfs 
iSCSI - - 
PhotonPersistentDisk V - 
Quobyte V Quobyte 
NFS - - 

RBD "A Ceph RBD 
VsphereVolume V vSphere 
PortworxVolume V Portworx Volume 
ScalelO V ScalelO 
StorageOS V StorageOS 
Local - Local 


后 续 文档 将 介绍 Kubernetes 如 何 与 Ceph RDB 和 CephFS 集 成 。 
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用 Helm 托 管 安装 Ceph 集 群 并 提供 后 端 存储 


本 文 翻译 自 Ceph 官 方 文档 ， 括 号 内 的 内 容 为 注释 。 


AUR 


ceph-helm 项 目 可 让 你 在 Kubernetes 环境 以 托管 方式 部 署 Ceph . 本 文档 假定 
Kubernetes 环境 已 经 可 用 。 


当前 的 限制 
e Public 网 络 和 Cluster 网 络 必 须 是 同一 个 网 络 


e 如 果 storage class 用 户 标 识 不 是 admin, 则 必须 在 Ceph 集 群 中 手动 创建 用 户 并 
在 Kubernetes 中 创建 其 secret 


~ 二 /一 


e ceph-mgr 只 能 运行 1 个 replica 


安装 并 使 用 Helm 


可 以 按照 此 说 明 instructions 安 装 Helm 。 
Helm 通 过 从 本 地 读 取 Kubernetes 配 置 文件 来 查找 Kubernetes 集 群 ; 确保 文件 已 下 载 
和 且 helm 客 户 端 可 以 访问 。 


Kubernetes 群 集 必须 配置 并 运行 Tiller 服 务 器 ， 并 且 须 将 本 地 Helm 客 户 端 网 络 可 
达 。 查 看 init 的 Helm 文 档 获 取 帮 助 。 要 在 本 地 运行 Tiler 并 将 Helm 连 接 到 它 ， 请 运行 
如 下 命令 (此 命令 会 在 Kubernetes 集 群 部 署 一 个 tiller 实 例 ) 


$ helm init 


ceph-helm 项 目 默 认 使 用 本 地 的 Helm repo Z-fi& charts ° 3&8 35 4 3 Helm repo 服 


务 器 ， 请 运行 : 


$ helm serve & 
$ helm repo add local http://localhost:8879/charts 


添加 Ceph-Helm charts 到 本 地 repo 


$ git clone https://github.com/ceph/ceph-helm 
$ cd ceph-helm/ceph 
$ make 


配置 Ceph 集 群 


创建 一 个 包含 Ceph 配 置 的 ceph-overrides.yaml 文 件 。 这 个 文件 可 能 存在 于 任何 地 
方 ， 本 文档 默认 此 文件 在 用 户 的 home 目 录 中 。 


$ cat -/ceph-overrides.yaml 


network: 
public: 172.21.0.0/20 
cluster: 172.21.0.0/20 


osd devices: 

- name: dev-sdd 
device: /dev/sdd 
zap: "1" 

- name: dev-sde 
device: /dev/sde 
zap: "1" 


storageclass: 
name: ceph-rbd 


pool: rbd 
user_id: k8s 


注意 如 果 未 设置 日 志 (journal) 设备 ， 它 将 与 device 设 备 同 位 置 。 另 ceph- 
helm/ceph/ceph/values.yaml 文 件 包含 所 有 可 配置 的 选项 。 


创建 Ceph 集群 的 namespace 


默认 情况 下 ，ceph-helm 组 件 在 Kubernetes 的 ceph namespace 中 运行 。 如 果 要 自 定 
义 ， 请 自 定义 namespace 的 名 称 ， 上 默认 namespace 请 运行 : 


$ kubectl create namespace ceph 


配置 RBAC 权 限 


Kubernetes> = v1.6 使 RBAC 成 为 默认 的 admission controller 。ceph-helm 要 为 每 个 
组 件 提供 RBAC 角 色 和 权限 : 


$ kubectl create -f -/ceph-helm/ceph/rbac.yaml 


rbac.yaml 文 件 假定 Ceph 集 群 将 部 署 在 ceph 命 名 空间 中 。 


?5 Kubelet ? 447 1% & 
需要 设置 以 下 标签 才能 部 署 Ceph 集 群 : 


ceph-mon=enabled 
ceph-mgr=enabled 
ceph-osd=enabled 
ceph-osd-device-<name>=enabled 


ceph-osd-device-1& 4 = Æ T 4&1 49 ceph-overrides.yaml ¥ © 3: 0sd_devices 2 fi 
值 创建 的 。 从 我 们 下 面 的 例子 中 ， 我 们 将 得 到 以 下 两 个 标签 : ceph-osd-device- 
dev-sdb 和 ceph-osd-device-dev-sdc。 


每 个 Ceph Monitor 节 点 


$ kubectl label node <nodename> ceph-mon=enabled ceph-mgr=enable 
d 


每 个 OSD node 节 点 


$ kubectl label node <nodename> ceph-osd=enabled ceph-osd-device 
-dev-sdb=enabled ceph-osd-device-dev-sdc=enabled 


Ceph 部 署 
运行 helm install 命 令 来 部 署 Ceph : 


$ helm install --name=ceph local/ceph --namespace=ceph -f ~/ceph 


-overrides.yaml 

NAME : ceph 

LAST DEPLOYED: Wed Oct 18 22:25:06 2017 
NAMESPACE: ceph 

STATUS: DEPLOYED 


RESOURCES: 

==> vi/Secret 

NAME TYPE DATA AGE 
ceph-keystone-user-rgw Opaque 7 1s 


==> vi/ConfigMap 


NAME DATA AGE 

ceph-bin-clients 2 1s 

ceph-bin 24 1s 

ceph-etc 1 1s 

ceph-templates 5 1s 

==> vi/Service 

NAME CLUSTER- IP EXTERNAL-IP  PORT(S) AGE 

ceph-mon None «none» 6789/TCP 1s 

ceph-rgw 310.101.219.239 <none> 8088/TCP is 

==> vibetai/DaemonSet 

NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE 
NODE-SELECTOR AGE 

ceph-mon 3 3 0 3 0 
ceph-mon=enabled 1s 

ceph-osd-dev-sde 3 3 0 3 0 
ceph-osd-device-dev-sde=enabled, ceph-osd=enabled 1s 

ceph-osd-dev-sdd 3 3 0 3 0 


ceph-osd-device-dev-sdd=enabled, ceph-osd=enabled is 


==> vibetal/Deployment 


NAME DESIRED CURRENT UP-TO-DATE AVAILABLE A 
GE 

ceph-mds 1 1 1 0 1 
S 

ceph-mgr 1 1 1 0 1 
S 

ceph-mon-check 1 1 1 0 1 
S 

ceph-rbd-provisioner 2 2 2 0 1 
S 

ceph-rgw 1 1 1 0 1 
S 

==> vi/Job 

NAME DESIRED SUCCESSFUL AGE 
ceph-mgr -keyring-generator 1 0 1s 
ceph-mds-keyring-generator 1 0 1s 
ceph-osd-keyring-generator 1 0 1s 
ceph-rgw-keyring-generator 1 0 1s 


ceph-mon-keyring-generator 1 0 1s 
ceph-namespace-client-key-generator 1 1s 
ceph-storage-keys-generator 1 0 1s 


e 


==> vi/StorageClass 
NAME TYPE 
ceph-rbd ceph.com/rbd 


helm install 的 输出 显示 了 将 要 部 署 的 不 同类 型 的 资源 。 


将 使 用 ceph-rbd-provisioner Pod 创 建 ceph.com/rbd 类 型 的 名 为 ceph-rbd 的 
StorageClass。 这 允许 创建 PVC 时 自动 提供 RBD。 第 一 次 挂 载 持 ，RBD 设 备 将 被 格 
式 化 (format) 。 所 有 RBD 设 备 都 将 使 用 ext4 文 件 系 统 。ceph.com/rbd 不 支持 
fsType 选 项 。 默 认 情 况 下 ，RBD 将 使 用 镜像 格式 2 和 镜像 分 层 特 性 。 可 以 在 values 
文件 中 覆盖 以 下 storageclass 的 默认 值 : 


storageclass: 
name: ceph-rbd 
pool: rbd 


user id: k8s 

user secret name: pvc-ceph-client-key 
image format: "2" 

image features: layering 


使 用 下 面 的 命令 检查 所 有 Pod 是 否 正常 运行 。 这 可 能 需要 几 分钟 时 间 : 


$ kubectl -n ceph get pods 
NAME 
ARTS AGE 
ceph-mds-3804776627-976z9 
1m 
ceph-mgr-3367933990-b368c 
1m 
ceph-mon-check-1818208419 -Ovkb7 
1m 
ceph-mon-cppdk 
1m 
ceph-mon-t4stn 
1m 
ceph-mon-vqz10 
1m 
ceph-osd-dev-sdd-6dphp 
1m 
ceph-osd-dev-sdd-6w7ng 
1m 
ceph-osd-dev-sdd-180vv 
1m 
ceph-osd-dev-sde-6dq6w 
1m 
ceph-osd-dev-sde-kqtor 
1m 
ceph-osd-dev-sde-1p2pf 
1m 
ceph-rbd-provisioner -2099367036-4prvt 
1m 
ceph-rbd-provisioner -2099367036-h9kw7 
1m 
ceph- rgw-3375847861-4wr74 
1m 


READY 


0/1 


1/1 


171 


3/3 


3/3 


3/3 


1/1 


1/1 


1/1 


1/1 


1/1 


1/1 


1/1 


1/1 


0/1 


STATUS 

Pending 
Running 
Running 
Running 
Running 
Running 
Running 
Running 
Running 
Running 
Running 
Running 
Running 
Running 


Pending 


REST 


注意 因为 我 们 没有 用 ceph-rgw = enabled Xceph-mds = enabled 给 节点 打 标 签 
(ceph 对 象 存 储 特性 需要 ceph-rgw，cephfs 特 性 需要 ceph-mds) ， ee. 
RGW Pod 都 处 于 pending 状 态 ， 一 旦 其 他 Pod 都 在 运行 状态 ， 请 用 如 下 命令 从 某 


MON 节 点 检查 Ceph 的 集群 状态 : 


$ kubectl -n ceph exec -ti ceph-mon-cppdk -c ceph-mon -- ceph -s 
cluster: 

id: e8f9da03-c2d2-4ad3-b807-2a13d0775504 

health: HEALTH. OK 


services: 
mon: 3 daemons, quorum mirai115,mira110,mira109 
mgr: mirai09(active) 
osd: 6 osds: 6 up, 6 in 


data: 
pools: © pools, © pgs 
objects: © objects, © bytes 
usage: 644 MB used, 5555 GB / 5556 GB avail 


pgs: 


配置 一 个 POD 以 便 从 Ceph 申 请 使 用 一 个 持久 卷 


A ~/ ceph-overwrite.yaml 中 定义 的 k8s 用 户 创建 一 个 密 钥 环 ， 并 将 其 转换 为 
base64 : 


$ kubectl -n ceph exec -ti ceph-mon-cppdk -c ceph-mon -- bash 

# ceph auth get-or-create-key client.k8s mon ‘allow r' osd ‘allo 
w rwx pool-rbd' | base64 

QVFCLzdPaFoxeUxCRV JBQUVEVGdHCE9YUSBYMVBSdURHUEUOTOE9PQo- 

# exit 


编辑 ceph namespace ¥ 7 7 49 A P secret : 


$ kubectl -n ceph edit secrets/pvc-ceph-client-key 


将 base64 值 复制 到 key 位 置 的 值 并 保存 : : 


apiVersion: v1 
data: 
key: QVFCLzdPaFoxeUxCRV JBQUVEVGdHCE9YUSBYMVBSdURHUEUOTOE9PQo- 
kind: Secret 
metadata: 
creationTimestamp: 2017-10-19T17:34:04Z 
name: pvc-ceph-client-key 
namespace: ceph 
resourceVersion: "8665522" 
selfLink: /api/vi/namespaces/ceph/secrets/pvc-ceph-client-key 
uid: b4085944-b4f3-11e7-add7-002590347682 
type: kubernetes.io/rbd 


我 们 创建 一 个 在 default namespace F 1% M RBD&j Pod » 44 7] P secret. ceph 
namespace X +] $| default namespace : 


$ kubectl -n ceph get secrets/pvc-ceph-client-key -o json | jq ' 
.metadata.namespace - "default"' | kubectl create -f - 

secret "pvc-ceph-client-key" created 

$ kubectl get secrets 


NAME TYPE DATA 
AGE 

default-token-r43wl kubernetes.io/service-account-token 3 
61d 

pvc-ceph-client-key kubernetes.io/rbd 1 
20s 

创建 并 初始 化 RBD 池 : 
$ kubectl -n ceph exec -ti ceph-mon-cppdk -c ceph-mon -- ceph os 


d pool create rbd 256 

pool 'rbd' created 

$ kubectl -n ceph exec -ti ceph-mon-cppdk -c ceph-mon -- rbd poo 
l init rbd 


重要 重要 的 Kubernetes(% Jt] RBD 7% 12444 RBDER AT 9| + Hu ° Luminous $ X 
CRUSH TUNABLES 5 (Jewel) 。 这 些 可 调 参数 的 最 小 内 核 版 本 是 4.5。 如 果 您 的 
内 核 不 支持 这 些 可 调 参数 ， 请 运行 ceph osd crush tunables hammer ° 


重要 由 于 RBD 映 射 到 主机 系统 上 。 主 机 需要 能 够 解析 由 kube-dns 服 务 管理 的 ceph- 
mon.ceph.svc.cluster.local 名 称 。 要 获得 kube-dns 服 务 的 IP 地 址 ， 运 行 kubectl -n 
kube-system get svc/kube-dns ° 


创建 一 个 PVC : 


$ cat pvc-rbd.yaml 


kind: PersistentVolumeClaim 
apiVersion: vi 
metadata: 
name: ceph-pvc 
spec: 
accessModes: 
- ReadwriteOnce 
resources: 
requests: 
storage: 20Gi 
storageClassName: ceph-rbd 


$ kubectl create -f pvc-rbd.yaml 
persistentvolumeclaim "ceph-pvc" created 
$ kubectl get pvc 


NAME STATUS VOLUME 

CAPACITY ACCESSMODES STORAGECLASS AGE 

ceph-pvc Bound pvc-1c2ada50-b456-11e7-add7-002590347682 
206i RWO ceph- rbd 3s 


检查 集群 上 是 否 已 创建 RBD : 


$ kubectl -n ceph exec -ti ceph-mon-cppdk -c ceph-mon -- rbd 1s 
kubernetes -dynamic - pvc -1c2e9442 -b456 -11e7 - 9bd2 -2a4159ce3915 
$ kubectl -n ceph exec -ti ceph-mon-cppdk -c ceph-mon -- rbd inf 


o kubernetes-dynamic - pvc -1c2e9442-b456-11e7 -9bd2-2a4159ce3915 
rbd image 'kubernetes-dynamic-pvc-1c2e9442-b456-11e7-9bd2-2a4159 
ce3915': 

size 20480 MB in 5120 objects 

order 22 (4096 kB objects) 

block_name_prefix: rbd_data.10762ae8944a 

format: 2 

features: layering 

flags: 

create_timestamp: Wed Oct 18 22:45:59 2017 


创建 一 个 使 用 此 PVC 的 Pod : 


$ cat pod-with-rbd.yaml 


kind: Pod 
apiVersion: vi 
metadata: 
name: mypod 
spec: 
containers: 
- name: busybox 
image: busybox 
command: 
- sleep 
= "3600" 
volumeMounts: 
- mountPath: "/mnt/rbd" 
name: voli 
volumes: 
- name: voli 
persistentVolumeClaim: 
claimName: ceph-pvc 


$ kubectl create -f pod-with-rbd.yaml 
pod "mypod" created 


检查 Pod : 


$ kubectl get pods 

NAME READY STATUS RESTARTS AGE 

mypod 1/1 Running 0 17s 

$ kubectl exec mypod -- mount | grep rbd 

/dev/rbdO on /mnt/rbd type ext4 (rw, relatime, stripe=1024, data=or 


dered) 


ASG 


可 以 通过 kubectl logs [-f] 4? 4-7 I OSD#eMonitor A & » Monitors 2 ^A & k 
流 ， 每 个 流 都 可 以 从 ceph-mon Pod 中 的 容器 访问 。 


在 ceph-mon Pod 中 有 3 个 容器 运行 : ceph-mon， 相 当 于 物理 机 上 的 ceph- 
mon.hostname.log ，cluster-audit-log-tailer 相 当 于 物理 机 上 的 ceph.audit.log * 
cluster-log-tailer 相 当 于 物理 机 上 的 ceph.log 或 ceph -w。 每 个 容器 都 可 以 通过 -- 
container 或 -Cc 选项 访问 。 例 如 ， 要 访问 cluster-tail-log， 可 以 运行 : 


$ kubectl -n ceph logs ceph-mon-cppdk -c cluster-log-tailer 
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使 用 Ceph 做 持久 化 存储 创建 MySQL 和 集群 


本 文中 用 到 的 yaml 文件 可 以 在 ../manifests/mariadb-cluster 目录 下 找到 。 


下 面 我 们 以 部 署 一 个 高 可 用 的 MySQL 集群 为 例 ， 讲 解 如 何 使 用 Ceph 做 数据 持久 
化 ， 其 中 使 用 StorageClass 动态 创建 PV，Ceph 集群 我 们 使 用 kubernetes 集群 外 
部 的 已 有 的 集群 ， 我 们 没有 必要 重新 部 署 了 。 


在 1.4 以 后 ，kubernetes 提供 了 一 种 更 加 方便 的 动态 创建 PV 的 方式 ; 也 就 是 说 使 
用 StoragaClass 时 无 需 预 先 创建 固定 大 小 的 PV， 等 待 使 用 者 创建 PVC 来 使 用 ; 
而 是 直接 创建 PVC 即 可 分 配 使 用 。 


使 用 kubernetes 和 集群 外 部 的 Ceph 存储 


在 部 署 kubernetes 之 前 我 们 就 已 经 有 了 Ceph 集群 ， 因 此 我 们 可 以 直接 拿 来 用 。 
但 是 kubernetes 的 所 有 节点 (AH master 节点 ) 上 依然 需要 安装 ceph 客户 


Am o 


yum install -y ceph-common 


还 需要 将 ceph 的 配置 文件 ceph.conf 放 在 所 有 节点 的 /etc/ceph ARF ° 
Kubernetes 使 用 ceph 存储 需要 用 到 如 下 配置 : 


e Monitors: Ceph montors 列表 

e Path : 作为 挂 载 的 根 路 径 ， 默 认 是 / 

e User : RADOSH P £ > RUX admin 

e secretFile : keyring 文件 路 径 ， 黑 认 是 /etc/ceph/usersecret， 我 们 Ceph 集群 
提供 的 文件 是 ceph.client.admin.keyring ， 将 在 下 面 用 到 

e secretRef : Ceph 认证 secret 的 引用 ， 如 果 配 置 了 将 会 覆盖 secretFile。 

e readOnly : 该 文件 系统 是 否 只 读 。 


Galera Cluster’) 22 


Galera 是 一 个 MySQL( 也 支持 MariaDB，Percona) 的 同步 多 主 集群 软件 。 


从 用 户 视角 看 ， 一 组 Galera 集 群 可 以 看 作 一 个 具有 多 入 口 的 MySQL 库 ， 用 户 可 以 同 
时 从 多 个 IP 读 写 这 个 库 。 目 前 Galera 已 经 得 到 广泛 应 用 ， 例 如 Openstack 中 ， 在 集 

群 规模 不 大 的 情况 下 ， 稳 定性 已 经 得 到 了 实践 考验 。 引 正 的 multi-master， 即 所 有 

节点 可 以 同时 读 写 数据 库 。 


详细 步骤 


以 下 步骤 包括 创建 Ceph 的 配置 和 MySQL 的 配置 两 部 分 。 


配置 Ceph 


关于 Ceph 的 yaml 文件 可 以 在 ../manifest/mariadb-cluster 目录 下 找到 。 


1. 生成 Ceph secret 


使 用 Ceph 管理 员 提 供给 你 的 ceph.client.admin.keyring 文件 ， 我 们 将 它 放 
在 了 /etc/ceph 目录 下 ， 用 来 生成 secret。 


grep key /etc/ceph/ceph.client.admin.keyring |awk '{printf "%s", 
$NF}' |base64 


ACOS ëO 
将 获得 加 密 后 的 
key > QVFDWDA2aFo5TG5TQnhBQV11bOlUL2V3YlRSaEtwVEhPWkxvUlE9PQ-- ° 我 
们 将 在 后 面 用 到 。 

创建 租户 namespace 


创建 galera-namespace.yaml 文件 内 容 为 : 


apiVersion: vi 
kind: Namespace 
metadata: 

name: galera 


3. 创建 Ceph secret 


创建 ceph-secret.yaml 文件 内 容 为 : 


apiVersion: v1 
kind: Secret 
metadata: 
name: ceph-secret 
namespace: galera 
type: "kubernetes.io/rbd" 
data: 
key: QVFDWDA2aFo5TG5TQnhBQV11bOlUL2V3YlRSaEtwVEhPWkxvUlE9PQ-- 


4. 创建 StorageClass 


创建 ceph-class.yaml 文件 内 容 为 : 


apiVersion: storage.k8s.io/vi 
kind: StorageClass 
metadata: 
name: ceph-web 
provisioner: kubernetes.io/rbd 
parameters: 
monitors: 172.28.7.98,172.28.7.99,172.28.7.100 
adminlId: admin 
adminSecretName: ceph-secret 
adminSecretNamespace: galera 
pool: rbd # 此 处 默认 是 rbd 池 ， 生 产 上 建议 自己 创建 存储 池 隔 离 
userId: admin 
userSecretName: ceph-secret 


此 配置 请 参考 kubernetes 官方 文 
档 : https://kubernetes.io/docs/concepts/storage/persistent-volumes/#ceph-rbd 


配置 MySQL 


1. 创建 MySQL 配置 文件 


创建 mysql-config.yaml 文件 内 容 为 : 


使 用 Ceph 做 持久 化 存储 


apiVersion: v1 
kind: ConfigMap 
metadata: 
name: mysql-config-vol 
namespace: galera 
labels: 
app: mysql 
data: 
mariadb.cnf: | 
[client] 
default-character-set 
[mysqld] 
character -set-server 
collation-server 
# InnoDB optimizations 
innodb log file size = 64M 
galera.cnf: | 
[galera] 
user - mysql 
bind-address - 0.0.0.0 
# Optimizations 
innodb flush log at trx commit = 0 
sync binlog = 0 
expire logs days - 7 
# Required settings 
default storage engine - InnoDB 
binlog format - ROW 
innodb autoinc lock mode - 2 
query cache size = 0 
query cache type = 0 
# MariaDB Galera settings 
#wsrep_debug=ON 
wsrep_on=ON 
wsrep provider-/usr/lib/galera/libgalera smm.so 
wsrep sst method-rsync 
# Cluster settings (automatically updated) 
wsrep. cluster address-gcomm:// 
wsrep cluster name-galera 
wsrep. node address-127.0.0.1 


utf8 


utf8 
utf8 general ci 





2. 创建 MySQL root 用 户 和 密码 
创建 加 密 密 码 


$ echo -n jimmysong|base64 
amltbXlzb25n 


注意 : 一 定 要 用 -n 去 掉 换 行 符 ， 不 然 会 报错 。 
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4] 3 root 用 户 


$ echo -n root |base64 
cm9vdA== 


创建 MySQL secret 


创建 mysgl-secret.yaml 文件 内 容 为 : 


apiVersion: v1 

kind: Secret 

metadata: 
name: mysql-secrets 
namespace: galera 
labels: 

app: mysql 

data: 
# Root password: changeit run echo -n jimmysong|base64 
root-password: amltbXlzb25n 
# Root user: root 
root-user: cm9vdA== 


3. 创建 yaml 配置 文件 


创建 MySQL 的 yaml 文件 galera-mariadb.yaml 内 容 为 : 


apiVersion: v1 
kind: Service 
metadata: 
annotations: 
service.alpha.kubernetes.io/tolerate-unready-endpoints: "tru 
B 
name: mysql 
namespace: galera 


labels: 
app: mysql 
tier: data 
spec: 
ports: 
- port: 3306 


name: mysql 
clusterIP: None 
selector: 
app: mysql 
apiVersion: apps/vibetai 
kind: StatefulSet 


使 用 Ceph 做 持久 化 存储 


metadata: 
name: mysql 
namespace: galera 
spec: 
serviceName: "mysql" 
replicas: 3 
template: 
metadata: 
labels: 
app: mysql 
tier: data 
annotations: 
pod.beta.kubernetes.io/init-containers: '[ 
{ 
"name": "galera-init", 
"image": "harbor-001.jimmysong.io/library/k8s-galera 
-init:latest", 
"args": ["-service=mysql"], 
"env": [ 
{ 
"name": "POD_NAMESPACE", 
"valueFrom": { 
"fieldRef": { "apiVersion": "vi", "fieldPath": 
"metadata.namespace" } 


} 
i 
{ 
"name": "SAFE_TO_BOOTSTRAP", 
"value": "IH 
}, 
1 
"name": "DEBUG", 
"Value": Wu 
} 
1, 
"volumeMounts": [ 
{ 
"name": "config", 
"mountPath": "/etc/mysql/conf.d" 
}, 
{ 
"name": "data", 
"mountPath": "/var/lib/mysql" 
} 
] 
} 
i 
spec: 
terminationGracePeriodSeconds: 10 
containers: 


- name: mysql 
image: harbor-001.jimmysong.io/library/mariadb: 10.1 
imagePullPolicy: IfNotPresent 
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ports: 
- containerPort: 3306 
name: mysql 
- containerPort: 4444 
name: sst 
- containerPort: 4567 
name: replication 
- containerPort: 4568 
name: ist 
env: 
- name: MYSQL ROOT PASSWORD 
valueFrom: 
secretKeyRef: 
name: mysql-secrets 
key: root-password 
- name: MYSQL ROOT USER 
valueFrom: 
secretKeyRef: 
name: mysql-secrets 
key: root-user 
- name: MYSQL INITDB SKIP TZINFO 
value: "yes" 
livenessProbe: 
exec: 
command: ["sh", "-c", "mysql -uN"$(MYSQL ROOT USER: - 


root}\" -pN'$(MYSQL ROOT PASSWORD)N" -e 'show databases;'"] 
initialDelaySeconds: 60 
timeoutSeconds: 5 
readinessProbe: 
exec: 
command: ["sh", "-c", "mysql -uN"'$(MYSQL ROOT USER: - 
root}\" -pN'$(MYSQL ROOT PASSWORD)N" -e 'show databases;'"] 
initialDelaySeconds: 20 
timeoutSeconds: 5 
volumeMounts: 
- name: config 
mountPath: /etc/mysql/conf.d 
- name: data 
mountPath: /var/lib/mysql 
volumes: 
- name: config 
configMap: 
name: mysql-config-vol 
imagePullSecrets: 


- name: "registrykey" 


volumeClaimTemplates: 
- metadata: 
name: data 
annotations: 


volume.beta.kubernetes.io/storage-class: "ceph-web" #3 引用 


ceph class 的 类 
spec: 
accessModes: [ "ReadwriteOnce" ] 


resources: 
requests: 
storage: 3Gi 


图 





上 





部 署 MySQL 集群 
在 /etc/mariadb-cluster 目录 下 执行 : 


kubectl create -f . 


存在 issue * #4 Error creating rbd image: executable file not found in 
$PATH#38923 


问题 记录 


如 果 没 有 安装 ceph-common 的 话 ，kubernetes 在 创建 PVC 的 时 候 会 有 如 下 报错 


信息 : 
Events: 
FirstSeen LastSeen Count From SubObjec 
tPath Type Reason Message 
1h 12s 441 {persistentvolume-controller } 


Warning ProvisioningFailed Failed to provision 
volume with StorageClass "ceph-web": failed to create rbd image 


: executable file not found in $PATH, command output: 


检查 kube-controller-manager 的 日 志 将 看 到 如 下 错误 信息 : 


journalctl -xe -u kube-controller-manager 
rbd util.go:364] failed to create rbd image, output 


rbd.go:317] rbd: create volume failed, err: failed to create 
rbd image: executable file not found in $PATH, command output: 


这 是 因为 kube-controller-manager 主机 上 没有 安装 ceph-common 的 缘故 。 


但 是 安装 了 ceph-common 之 后 依然 有 问题 : 


Sep 4 15:25:36 bj-xg-oam-kubernetes-001 kube-controller-manager 
: W0904 15:25:36.032128 13211 rbd util.go:364] failed to creat 
e rbd image, output 

Sep 4 15:25:36 bj-xg-oam-kubernetes-001 kube-controller-manager 
: W0904 15:25:36.032201 13211 rbd util.go:364] failed to creat 
e rbd image, output 

Sep 4 15:25:36 bj-xg-oam-kubernetes-001 kube-controller-manager 
: W0904 15:25:36.032252 13211 rbd util.go:364] failed to creat 
e rbd image, output 

Sep 4 15:25:36 bj-xg-oam-kubernetes-001 kube-controller-manager 
: E0904 15:25:36.032276 13211 rbd.go:317] rbd: create volume f 
ailed, err: failed to create rbd image: fork/exec /usr/bin/rbd: 
invalid argument, command output: 


该 问题 尚未 解决 ， 参 考 Error creating rbd image: executable file not found in 
$PATHZ38923 


从 日 志 记 录 来 看 追查 到 pkg/volume/rbd/rbd.go 的 func (r 

*rbdVolumeProvisioner) Provision() (*vi.PersistentVolume, error) { 

方法 对 ceph-class.yaml 中 的 参数 进行 了 验证 和 处 理 后 调用 了 
pkg/volume/rbd/rdb utils.go 文件 第 344 行 CreateImage 方法 
(kubernetes v1.6.1 版 本 ) 


func (util *RBDUtil) Createlmage(p *rbdVolumeProvisioner) (r *v1. 
RBDVolumeSource, size int, err error) { 
var output []byte 


capacity :- p.options.PVC.Spec.Resources.Requests[v1.Resourc 
eName(vi.ResourceStorage) | 
volSizeBytes := capacity. Value() 


// convert to MB that rbd defaults on 
SZ := int(volume.RoundUpSize(volSizeBytes, 1024*1024)) 
volSz := fmt.Sprintf("%d", sz) 
// rbd create 
1 := len(p.rbdMounter.Mon) 
// pick a mon randomly 
start := rand.Int() % 1 
// iterate all monitors until create succeeds. 
for i := start; i < start+l; i++ { 
mon := p.Mon[i%1] 
glog.V(4).Infof("rbd: create %s size %s using mon %s, po 
ol %s id %s key %s", p.rbdMounter.Image, volSz, mon, p.rbdMounter 
.Pool, p.rbdMounter.adminId, p.rbdMounter.adminSecret ) 
output, err = p.rbdMounter.plugin.execCommand( "rbd", 


[]string{"create", p.rbdMounter.Image, "--size", vol 
Sz, "--pool", p.rbdMounter.Pool, "--id", p.rbdMounter.adminId, " 
-m", mon, "--key=" + p.rbdMounter.adminSecret, "--image-format", 
wa" +) 
if err == nil { 
break 
) else { 


glog.Warningf("failed to create rbd image, output 96v" 
, string(output) ) 


j 
j 


if err != nil ( 
return nil, 0, fmt.Errorf("failed to create rbd image: ?6 
v, command output: %s", err, string(output)) 


j 


return &vi.RBDVolumeSource( 
CephMonitors: p.rbdMounter.Mon, 
RBDImage: p.rbdMounter.Image, 
RBDPool: p.rbdMounter.Pool, 
^, sz, nil 





使 用 Ceph 做 持久 化 存储 
https://github.com/kubernetes/examples/blob/master/staging/volumes/cephfs/REA 
DME.md 

k8s-ceph-statefulsets-storageclass-nfs 动态 卷 有 状态 应 用 实践 

Kubernetes persistent storage with Ceph 
https://kubernetes.io/docs/concepts/storage/persistent-volumes/#ceph-rbd 

Error creating rbd image: executable file not found in $PATH#38923 
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OpenEBS 


o Go 语言 编写 的 基于 容器 的 块 存储 开源 软件 。OpenEBS 使 得 在 
器 中 运行 关键 性 任务 和 需要 数据 持久 化 的 负载 变 得 更 可 靠 。 


OpenEBS 由 CloudByte 研 发 ， 这 是 一 家 专业 做 容器 化 存储 的 公司 ，OpenEBS 是 其 

一 款 开 源 产 品 ，CloudByte 将 其 在 企业 级 容器 存储 的 经 验 付 诸 到 该 项 目 中 。 这 个 项 

目的 愿景 也 很 简单 ， 就 是 让 需要 持久 化 存储 的 工作 负载 中 的 存储 服务 能 够 直接 集成 
在 环境 中 ， 存 储 服 务 可 以 自动 管理 ， 将 存储 的 细节 隐藏 起 来 ， 就 像 存 储 系 统 是 另 一 
套 基础 架构 一 样 。 


我 们 知道 AWS 中 提供 了 EBS (Elastic Block Storage) ， 适 用 于 Amazon EC2 的 持 
久 性 块 存储 ， 可 以 满足 要 求 最 苛刻 的 应 用 程序 在 功能 和 性 能 方面 的 要 求 ， 
OpenEBS 即 其 开源 实现 。 


简介 


使 用 DpenEBS， 你 可 以 将 有 持久 化 数据 的 容器 ， 像 对 待 其 他 普通 容器 一 样 来 对 
待 。OpenEBS 本 身 也 是 通过 容器 来 部 署 的 ， ae ae Swarm ` Mesos ^ 
Rancher 编 排 调度 ， 存 储 服 务 可 以 分 派 给 每 个 pod、 应 用 程序 、 集 群 或 者 容器 级 
别 ， 包 括 : 


e 跨 节 点 的 数据 持久 化 

e 跨 可 用 区 和 云 厂商 的 数据 同步 

e 使 用 商业 硬件 和 容器 引擎 来 提供 高 可 扩展 的 块 存 储 

e 与 容器 编排 引擎 集成 ， 开 发 者 的 应 用 程序 可 以 自动 的 配置 DpenEBS 

e 基于 CloudByte 在 BSD 的 容器 化 经 验 ， 为 用 户 提供 OpenEBS 的 QoS 保证 


ARI 


OpenEBS 存 储 控制 器 本 身 就 运行 在 容器 中 。 gn Volume i1 — 4- 3 4- Af 
服务 方式 运行 的 容器 组 成 。 这 种 存储 控制 器 
由 其 自己 的 一 组 容器 来 提供 ， 而 不 是 由 一 个 das ode 制 的 ， 单 体 
(monolithic) 存储 控制 器 来 提供 。 这 就 是 DpenEBS 与 传统 存储 设备 的 本 质 区 别 。 





OpenEBS 
OpenEBS 的 架构 可 以 分 为 数据 平面 (Data Plane) 和 控制 平面 (Control Plane) 
两 部 分 


e 数据 平面 : 为 应 用 程序 提供 数据 存储 
e 控制 平面 : 管理 DpenEBS 卷 容器 ， 这 通常 会 用 到 容器 编排 软件 的 功能 


数据 平面 


下 图 是 OpenEBS 对 应 在 Kubernetes 集 群 上 部 署 的 架构 图 。 其 中 ， 黄 色 部 分 是 
OpenEBS 持 久 化 存储 卷 ， 通 过 Kubernetes 的 PV 来 创建 ， 使 用 iSCSI 来 实现 ， 数 据 
保存 在 node 节 点 上 或 者 云 中 的 卷 〈 如 EBS、GPD 等 ) ， o 集群 部 署 在 哪 


里 。OpenEBS 的 卷 完 全 独立 于 用 户 的 应 用 的 生命 周期 来 管理 ， 这 也 是 Kuberentes 
中 的 PV 的 基本 思路 


OpenEBS Cluster - Data Plane 
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图 片 - OpenEBS 集 群 数据 平面 (图 片 来 自 
https://github.com/openebs/openebs/blob/master/contribute/design/README.md 
) 


OpenEBS 卷 为 容器 提供 持久 化 存储 ， 具 有 针对 系统 故障 的 弹性 ， 更 快 地 访问 存 
储 ， 快 照 和 备份 功能 。 此 外 ， 它 还 提供 了 监控 使 用 情况 和 执行 QoS 策略 的 机 制 。 


Co 
o 
E 


5 f RTE) BERRA 4 UR 38 o 可 以 是 主机 目录 ， 附 加 块 设备 或 远程 磁盘 。 每 个 
OpenEBS 卷 包含 一 个 ISCSI 目 标 容 器 (在 上 图 中 表示 为 openebs-vol1) 和 一 个 或 多 
个 副本 容器 (openebs-vol1-R1 和 openebs-vol1-R2) ° 


应 用 程序 pod 通 过 iSCSI 目标 容器 访问 存储 ，iSCSI 目 标 容器 将 数据 复制 到 其 所 有 副 
need 点 故障 时 ，iSCSI 目 标 容器 将 从 剩余 的 其 中 一 个 在 线 节点 上 启动 ， 并 
连接 到 可 用 副本 容器 来 提供 数据 。 
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该 部 分 的 实现 包括 两 个 容器 


e openebs/jiva : 存储 控制 功能 ， 包 括 复制 逻辑 
e openebs/gotgt : 由 openebsyjiva 使 用 的 iSCSI 目标 功能 


控制 平面 


ven 制 平 面 又 叫做 存储 编排 或 maya。 目 的 是 为 了 创建 超 融合 的 OpenEBS ， 
将 其 挂 载 到 如 Kubernetes、Swarm、Nomad 等 容器 编排 调度 引擎 上 ， 用 来 扩展 特 
定 的 容器 编排 系统 提供 的 存储 功能 。 


OpenEBS 


OpenEBS Cluster - Control Plane 
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图 片 - OpenEBS 集 群 的 控制 平面 (图 片 来 自 


maya-apiserver maya-provisioner jaegar-maya (n) 


oad 


https://github.com/openebs/openebs/blob/master/contribute/design/README.md 


) 


OpenEBS 的 控制 平面 也 是 基于 微服 务 的 ， 它 的 服务 可 以 分 成 以 下 几 个 部 分 : 


e 容器 编排 插件 ， 用 于 增加 强 容器 编排 框架 的 功能 : 
o Kubernetes 动 态 配置 : openebs-provisioner 
o Kubernetes-dashboard : openebs-dashboard 
o 扩展 的 schema : 基于 Kubernetes 的 CRD ( 自 定义 资源 类 型 ) ， 存 储 
OpenEBS 相 关 的 配置 数据 
e 集群 服务 ， 提 供 OpenEBS 特 定 的 存储 智能 ， 如 : 


o maya-apiserver : 包含 执行 卷 操 作 的 API， 可 将 请 求 转换 为 容器 编排 系统 


特定 的 操作 
o maya-mulebot : 使 用 收集 的 信息 来 建议 优化 的 布局 和 事件 处 理 提示 


o maya-connect : 允许 将 监控 数据 上 传 到 maya-cloud ， 以 便 进 一 步 进 行 


存储 访问 模式 分 析 
e 节点 服务 ， 提 供 OpenEBS 特 定 的 随 kubelet 一 起 运行 的 存储 智能 ， 如 : 
o maya-agent : 包括 存储 管理 功能 


通过 使 用 prometheus、heapster、grafana 和 jaegar 进 行 上 述 服务 ， 可 以 添加 监控 和 


跟踪 功能 。 
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源码 


e openebs/maya : 所 有 特定 的 二 进 制 代码 ( 非 插 件 ) 都 存储 在 这 个 仓库 中 ， 比 
如 maya-apiserver 、 maya-agent 、 maya-mulebot 、 maya- 
connect 、 mayactl 等 等 。 

e openebs-dashboard : kubernetes-dashboard 项 目的 分 支 ， 扩 展 了 存储 功能 。 

e openebs-provisioner : % B Kubernetes##1t 4 Xt H 4) OpenEBS K8s 
Provisioner ° 


e https://www.openebs.io/ 

e https://github.com/openebs/openebs 

e Data Scientists adopting tools and solutions that allow them to focus more on 
Data Science and less on the infrastructure around them 


Copyright © jimmysong.io 2017-2018 all right reserved > powered by 
GitbookUpdated at 2018-05-09 14:15:47 


使 用 OpenEBS 做 持久 化 存储 


本 文 将 指导 您 如 何在 Kubernetes 集 群 上 安装 OpenEBS 作 为 持久 化 存储 。 


我 们 将 使 用 Operator 的 方式 来 安装 OpenEBS， 安 装 之 前 需要 先 确认 您 的 节点 上 已 经 
安装 了 iSCSI。 


先决 条 件 


OpenEBS 依 赖 与 iSCSI 做 存储 管理 ， 因 此 需要 先 确保 您 的 集群 上 已 有 安装 
OpenEBS 。 


注意 : 如 果 您 使 用 kubeadm， 容 器 方式 安装 的 kublet， 那 么 其 中 会 自 带 iSCSI， 不 需 
要 再 手动 安装 ， 如 果 是 直接 使 用 二 进 制 形式 在 裸 机 上 安装 的 kubelet， 则 需要 自己 安 
RISCSI ° 


iSCSI( Internet Small Computer System Interface 互联 网 小 型 计算 机 系统 接口 ) 是 一 
种 基于 TCP/IP 的 协议 ， 用 来 建立 和 管理 |P 存 储 设备 、 主 机 和 客户 机 等 之 间 的 相互 
连接 ， 并 创建 存储 区 域 网 络 (SAN) © SAN 使 得 SCSI 协议 应 用 于 高 速 数据 传输 网 
络 成 为 可 能 ， 这 种 传输 以 数据 块 级 别 (block-level) 在 多 个 数据 存储 网 络 间 进 行 。 
SCSI 结构 基于 C/S 模 式 ， 其 通常 应 用 环境 是 : 设备 互相 靠近 ， 并 且 这 些 设 备 由 
SCSI 总 线 连 接 。 


OpenEBS 需 要 使 用 iSCSI 作为 存储 协议 ， 而 CentOS 上 默认 是 没有 安装 该 软件 的 ， 
因此 我 们 需要 手动 安装 。 


iSCSI 中 包括 两 种 类 型 的 角色 : 


e target : 用 来 提供 存储 (server) 
e initiator : 使 用 存储 的 客户 端 (client) 


下 图 在 Kubernetes 中 使 用 iSCSI 的 架构 图 (图 片 来 源 : http://rootfs.github.io/iSCSI- 
Kubernetes/) 。 


Scheduler 
Storage Vendor (RHS, NTAP, EMC) 


/dev/sdb 


iSCSI initiator 


图 片 - Kubernetes iSCSI 74 





安装 iSCSI 服务 十 分 简单 ， 不 需要 额外 的 配置 ， 只 要 安装 后 局 动 服务 即 可 。 


在 每 个 node 节 点 上 执行 下 面 的 命令 : 


yum -y install iscsi-initiator-utils 
systemctl enable iscsid 
systemctl start iscsid 


快速 开始 
使 用 Operator 运 行 OpenEBS 服 务 : 


wget https://raw.githubusercontent.com/openebs/openebs/master/k8 
s/openebs-operator.yaml 
kubectl apply -f openebs-operator.yaml 


使 用 默认 或 自 定义 的 Storageclass : 


wget https://raw.githubusercontent .com/openebs/openebs/master/k8 
s/openebs-storageclasses.yaml 
kubectl apply -f openebs-storageclasses.yaml 


用 到 的 镜像 有 : 


openebs/m-apiserver:0.5.1-RC1 
openebs/openebs-k8s-provisioner:0.5.1-RC2 
openebs/jiva:0.5.1-RC1 
openebs/m-exporter:0.5.0 


i| 试 
下 面 使 用 OpenEBS 官 方 文档 中 的 示例 ， 安 装 Jenkins 测 试 


wget https://raw.githubusercontent.com/openebs/openebs/master/k8 
s/demo/jenkins/jenkins.yml 
kubectl apply -f jenkins.yml 


查看 PV 和 PVC 


$ kubectl get pv 


NAME CAPACITY ACCESS MOD 
ES RECLAIM POLICY STATUS CLAIM STORAG 
ECLASS REASON AGE 
pvc-8e203e86-f1e5-11e7-aa47-f4e9d49f8edO 5G RWO 

Delete Bound default/jenkins-claim openeb 
s-standard 1h 


$ kubectl get pvc 
kubectl get pvc 


NAME STATUS VOLUME 

CAPACITY ACCESS MODES STORAGECLASS AGE 
jenkins-claim Bound pvc -8e203e86 -f1e5-11e7 -aa47 - F4e9d49F 
8ed0 5G RWO openebs-standard 1h 


4 f Jenkins pod 


Events: 


Type Reason Age From 
Message 

Warning FailedScheduling 29m (x2 over 29m) default-sch 
eduler PersistentVolumeClaim is not bound: "jenkins-claim" ( 
repeated 3 times) 

Normal Scheduled 29m default-sch 
eduler Successfully assigned jenkins-668dfbd847-vhg4c to 17 
2.20.0.115 

Normal SuccessfulMountVolume 29m kubelet, 17 


2.20.0.115 MountVolume.SetUp succeeded for volume "default-toke 
n-319f9" 

Warning FailedMount 27m kubelet, 17 
2.20.0.115 Unable to mount volumes for pod "jenkins-668dfbd847- 
vhg4c default(8e2ad467-f1e5-11e7-aa47-f4e9d49f8ed0O)": timeout ex 
pired waiting for volumes to attach/mount for pod "default"/"jen 
kins-668dfbd847-vhg4c". list of unattached/unmounted volumes-[je 
nkins-home] 


Warning FailedSync 27m kubelet, 17 
2.20.0.115 Error syncing pod 
Normal SuccessfulMountVolume 26m kubelet, 17 


2.20.0.115 MountVolume.SetUp succeeded for volume "pvc-8e203e86 
-f1e5-11e7-aa47-f4e9d49f8ed0" 

Normal Pulling 26m kubelet, 17 
2.20.0.115 pulling image "harbor-001.jimmysong.io/library/jenki 
he: Its" 

Normal Pulled 26m kubelet, 17 
2.20.0.115 Successfully pulled image "harbor-001.jimmysong.io/l 
ibrary/jenkins:lts" 


Normal Created 26m kubelet, 17 
2.20.0.115 Created container 
Normal Started 26m kubelet, 17 


2.20.0.115 Started container 
E apu] wj 


启动 成 功 。Jenkins 配 置 使 用 的 是 NodePort 方 式 访问 ， 现 在 访问 集群 中 任何 一 个 节 
点 的 Jenkins service 的 NodePort 即 可 。 


G fi RY 


OpenEBS 的 存储 策略 使 用 StorageClaass 实 现 ， 包 括 如 下 的 StorageClass : 


e openebs-cassandra 
e openebs-es-data-sc 
e openebs-jupyter 


e openebs-kafka 

e openebs-mongodb 
e openebs-percona 

e openebs-redis 

e openebs-standalone 
e openebs-standard 
e openebs-zk 


# Storage Class 都 对 应 与 某 种 应 用 的 存储 模式 ， 使 用 方式 请 参考 OpenEBS 
Storage Policies ° 


e OpenEBS Documentation 

e CentOS 7.x 下 配置 iSCSI 网 络 存储 

e Configure iSCSI Initiator 

e RHEL7: Configure a system as either an iSCSI target or initiator that 
persistently mounts an iSCSI target. 
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Rook 


RookX — 3k x Jg E NR 8] F-38278 A E IR ABER LO BAY CH ACNCFHEM1E o 
Rook 的 官方 网 站 是 https://rook.io。 


Rook 1t A ? 


Rook 将 分 布 式 存储 软件 转变 为 自我 管理 ， 自 我 缩放 和 自我 修复 的 存储 服务 。 它 通过 
自动 化 部 署 ， 引 导 、 配 置 、 人 供应、 扩展、 升级、 迁移 、 灾 难 恢 复 、 监 控 和 资源 管理 
来 实现 。 Rook 使 用 基础 的 云 原生 容器 管理 、 调 度 和 编排 平台 提供 的 功能 来 履行 其 


RT 。 


^N 


Rook 利 用 扩展 点 深入 融入 云 原生 环境 ， 为 调度 、 生 命 周期 管理 、 资 源 管理 、 安 全 
性 、 监 控 和 用 户 体验 提供 无 颖 体验。 


Rook 现 在 处 于 alpha 状 态 ， 并 且 最 初 专注 于 在 Kubernetes 之 上 运行 Ceph。Ceph 有 是 
一 个 分 布 式 存储 系统 ， 提 供 文 件 、 数 据 块 和 对 象 存储 ， 可 以 部 署 在 大 型 生产 集群 
中 。Rook 计 划 在 未 来 的 版 本 中 增加 对 除 Ceph 之 外 的 其 他 存储 系统 以 及 Kubernetes 
之 外 的 其 他 云 原生 环境 的 支持 。 


oh 
可 以 使 用 helm 或 直接 用 yaml 文 件 两 种 方式 来 部 署 rook operator ° 


使 用 helm 部 署 


helm init -i jimmysong/kubernetes-helm-tiller:v2.8.1 
helm repo add rook-alpha https://charts.rook.io/alpha 
helm install rook-alpha/rook --name rook --namespace rook-system 


直接 使 用 yaml 文 件 部 署 


kubectl apply -f rook-operator.yaml 


不 论 使 用 那 种 方式 部 署 的 rook operator， 都 会 在 rook-agent 中 看 到 rook-agent 用 户 
无 法 列 出 集群 中 某 些 资源 的 错误 ， 可 以 通过 为 rook-agent 的 分 配 cluster- 
admin 权限 临时 解决 ， 详 见 lssue 1472 ° 


使 用 如 下 yanl 文 件 创 建 一 个 ClusterRoleBinding 并 应 用 到 集群 中 。 


kind: ClusterRoleBinding 
apiVersion: rbac.authorization.k8s.io/vibeta1 
metadata: 

name: rookagent-clusterrolebinding 
subjects: 

- kind: ServiceAccount 

name: rook-agent 

namespace: rook-system 
roleRef: 

kind: ClusterRole 

name: cluster-admin 

apiGroup: "" 


#8 X rook cluster 
创建 完 rook operator 后 ， 我 们 再 部 署 rook cluster ° 


rook-cluster.yaml 配置 如 下 : 


apiVersion: vi 
kind: Namespace 
metadata: 
name: rook 
apiVersion: rook.io/vialphai 
kind: Cluster 
metadata: 
name: rook 
namespace: rook 
spec: 
versionTag: v0.6.2 
dataDirHostPath: /var/lib/rook 
storage: 
useAllNodes: true 
useAllDevices: false 
storeConfig: 
storeType: bluestore 
databaseSizeMB: 1024 
journalSizeMB: 1024 


注意 : 需要 手动 指定 versionTag ， 因 为 该 镜像 repo 中 没有 latest 标签 ， 如 不 
指定 的 话 Pod 将 出 现 镜像 拉 取 错误 。 


执行 下 面 的 命令 部 署 rook 集 群 。 
kubectl apply -f rook-cluster.yaml 


rook 集 群 运行 在 rook namespace f > &A#Arook FF ¥ “pod : 


$ kubectl -n rook get pod 


NAME READY STATUS RESTARTS 
AGE 

rook-api-848df956bf-qezf2 1/1 Running 0 
4m 

rook-ceph-mgrO-cfccfd6b8-cpkb5p 1/1 Running 0 
4m 

rook-ceph-mon0-t4961 1/1 Running 0 
6m 

rook-ceph-mon1-zcn7v 1/1 Running 0 
5m 

rook-ceph-mon3-h97qx 1/1 Running 0 
3m 

rook-ceph-osd-557tn 1/1 Running 0 
4m 

rook-ceph-osd-74frb 1/1 Running 0 
4m 

rook-ceph-osd-zf7rg 1/1 Running 1 
4m 

rook-tools 1/1 Running 0 
2m 


#8 X StorageClass 


StorageClass rook-block 的 yaml 文 件 〈rook-storage.yaml) 如 下 : 


Rook 


apiVersion: rook.io/vialphai 
kind: Pool 
metadata: 

name: replicapool 

namespace: rook 
spec: 

replicated: 

size: 1 

# For an erasure-coded pool, comment out the replication size 
above and uncomment the following settings. 

# Make sure you have enough OSDs to support the replica size o 
r erasure code chunks. 

#erasureCoded: 

# dataChunks: 2 

# codingChunks: 1 
apiVersion: storage.k8s.io/vi 
kind: StorageClass 
metadata: 

name: rook-block 

provisioner: rook.io/block 
parameters: 

pool: replicapool 

# Specify the Rook cluster from which to create volumes. 

# If not specified, it will use `rook` as the name of the clus 
ter. 

# This is also the namespace where the cluster will be 

clusterName: rook 

# Specify the filesystem type of the volume. If not specified, 
it will use "ext4'. 

# fstype: ext4 


我 们 在 下 面 的 示例 中 将 使 用 rook-block 这 个 StorageClass 来 创建 PV。 


工具 


部 署 rook 操 作 工 具 pod， 该 工具 pod 的 yaml 文 件 (rook-tools.yaml) 如 下 : 


906 


apiVersion: v1 
kind: Pod 
metadata: 
name: rook-tools 
namespace: rook-system 
spec: 
dnsPolicy: ClusterFirstWwithHostNet 
serviceAccountName: rook-operator 
containers: 
- name: rook-tools 
image: rook/toolbox:master 
imagePullPolicy: IfNotPresent 
env: 
- name: ROOK ADMIN SECRET 
valueFrom: 
secretKeyRef : 
name: rook-ceph-mon 
key: admin-secret 
securityContext: 
privileged: true 
volumeMounts: 
- mountPath: /dev 
name: dev 
- mountPath: /sys/bus 
name: sysbus 
- mountPath: /lib/modules 
name: libmodules 
- name: mon-endpoint-volume 
mountPath: /etc/rook 
hostNetwork: false 
volumes: 
- name: dev 
hostPath: 
path: /dev 
- name: sysbus 
hostPath: 
path: /sys/bus 
- name: libmodules 
hostPath: 
path: /lib/modules 
- name: mon-endpoint-volume 
configMap: 
name: rook-ceph-mon-endpoints 
items: 
- key: endpoint 
path: mon-endpoints 


ConfigMap 和 Secret 中 的 配置 项 内 容 是 自 定 义 的 。 


使 用 下 面 的 命令 部 署 工具 pod : 


kubectl apply -f rook-tools.yaml 


这 是 一 个 独立 的 pod， 没 有 使 用 其 他 高 级 的 controller 来 管理 ， 我 们 将 它 部 署 
在 rook-system 的 namespace 下 。 


kubectl -n rook exec -it rook-tools bash 


使 用 下 面 的 命令 查看 rook 集 群 状态 。 


$ rookctl status 
OVERALL STATUS: OK 


USAGE : 

TOTAL USED DATA AVAILABLE 

37.95 GiB 1.50 GiB o B 36.45 GiB 

MONITORS: 

NAME ADDRESS IN QUORUM STATUS 
rook-ceph-monO 10.254.162.99:6790/0 true UNKNOWN 
MGRs: 

NAME STATUS 


rook-ceph-mgrO Active 


OSDs: 
TOTAL UP IN FULL NEAR FULL 
1 1 1 false false 


PLACEMENT GROUPS (0 total): 
STATE COUNT 
none 


$ ceph df 
GLOBAL : 
SIZE AVAIL RAW USED %RAW USED 
38861M 37323M 1537M 3.96 
POOLS: 
NAME ID USED %USED MAX AVAIL OBJECTS 


示例 


官方 提供 了 使 用 rook 作 为 典型 的 LAMP (Linux + Apache + MySQL + PHP) 应 用 
Wordpress 的 存储 后 端的 示例 的 yaml 文 件 mysql.yaml 和 wordpress.yaml ， 使 
用 下 面 的 命令 创建 。 


kubectl apply -f mysql.yaml 
kubectl apply -f wordpress.yaml 


Wordpress 要 依赖 于 MySQL， 所 以 要 先 创建 MySQL » 

在 创建 wordpress 的 时 候 可 能 遇 到 该 错误 rook flexvolume failing to attach volumes 
#1147， 该 问题 尚未 解决 。 

清理 

如 果 使 用 helm 部 署 ， 则 执行 下 面 的 命令 : 


helm delete --purge rook 
helm delete daemonset rook-agent 


如 果 使 用 yaml 文 件 直接 部 署 ， 则 使 用 kubectl delete -f 加 当初 使 用 的 yaml 文 件 
即 可 删除 集群 。 


e Operator Helm Chart 
e Creating Rook Clusters 
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NFS (Network File System) 网 络 文件 系统 


NFS (Network File System) 即 网 络 文件 系统 ， 是 FreeBSD 支 持 的 文件 系统 中 的 一 
种 ， 它 允许 网 络 中 的 计算 机 之 间 通 过 TCP/IP 网 络 共享 资源 。 在 NFS 的 应 用 中 ， 本 地 
NFS 的 客户 端 应 用 可 以 透明 地 读 写 位 于 远 端 NFS 服 务 器 上 的 文件 ， 就 像 访 问 本 地 文 
件 一 样 。 在 Linux 系 统 中 ，NFS 也 作为 一 种 简单 的 网 络 共享 文件 系统 而 存在 。 
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利用 NFS 动 态 提供 Kubernetes 后 端 存储 卷 


本 文 翻译 自 nfs-client-provisioner 的 说 明文 档 ， 本 文 将 介绍 使 用 nfs-client- 
provisioner 这 个 应 用 ， 利 用 NFS Server 给 Kubernetes 作 为 持久 存储 的 后 端 ， 并 且 动 
态 提供 PV。 前 提 条 件 是 有 已 经 安装 好 的 NFS 服 务 器 ， 并 且 NFS 服 务 器 与 
Kubernetes 的 Slave 节 点 都 能 网 络 连通 。 所 有 下 文 用 到 的 文件 来 自 于 git clone 
https://github.com/kubernetes-incubator/external-storage.git 的 nfs- 
client 目 录 。 


nfs-client-provisioner 


nfs-client-provisioner 是 一 个 Kubernetes 的 简易 NFS 的 外 部 provisioner， 本 身 不 提 
供 NFS， 需 要 现 有 的 NFS 服 务 器 提供 存储 


e PV 以 ${namespace}-${pvcName}-${pvName} 的 命名 格式 提供 (在 NFS 服 务 
ZŁ) 

e PV 回收 的 时 候 以 archieved-${namespace}-${pvcName}-${pvName} 的 命 
名 格式 (在 NFS 服 务 器 上 ) 


> xz 
安装 部 署 
e 修改 deployment 文 件 并 部 署 deploy/deployment.yaml 


需要 修改 的 地 方 只 有 NFS 服 务 器 所 在 的 IP 地 址 (10.10.10.60) ， 以 及 NFS 服 务 器 共 
享 的 路 径 ( /ifs/kubernetes ) ， 两 处 都 需要 修改 为 你 实际 的 NFS 服 务 器 和 共享 
目录 


kind: Deployment 
apiVersion: extensions/vibetai 
metadata: 
name: nfs-client-provisioner 
spec: 
replicas: 1 
strategy: 
type: Recreate 
template: 
metadata: 
labels: 
app: nfs-client-provisioner 
spec: 
serviceAccountName: nfs-client-provisioner 
containers: 
- name: nfs-client-provisioner 
image: quay.io/external_storage/nfs-client-provisioner: 
latest 
volumeMounts: 
- name: nfs-client-root 
mountPath: /persistentvolumes 
env: 
- name: PROVISIONER_NAME 
value: fuseim.pri/ifs 
- name: NFS_SERVER 
value: 10.10.10.60 
- name: NFS_PATH 
value: /ifs/kubernetes 
volumes: 
- name: nfs-client-root 
nfs: 
server: 10.10.10.60 
path: /ifs/kubernetes 


lE w( 
e 修改 StorageClass 文 件 并 部 署 deploy/class.yaml 


此 处 可 以 不 修改 ， 或 者 修改 provisioner 的 名 字 ， 需 要 与 上 面 的 deployment 的 
PROVISIONER_NAME 名 字 一 致 。 


apiVersion: storage.k8s.io/vi 
kind: StorageClass 
metadata: 

name: managed-nfs-storage 
provisioner: fuseim.pri/ifs 


授权 


io 的 集群 启用 了 RBAC ， 或 者 您 正在 运行 OpenShift， 则 必须 授权 provisioner 。 
果 你 在 非 默 认 的 “default* 名 称 空间 /项 目 之 外 部 署 ， 可 以 编 
: deploy/auth/clusterrolebinding.yaml 或 编辑 "oadm policy"4& 4 » 


te Ke A T RBAC 
需要 执行 如 下 的 命令 来 授权 。 


$ kubectl create -f deploy/auth/serviceaccount.yaml 
serviceaccount "nfs-client-provisioner" created 

$ kubectl create -f deploy/auth/clusterrole.yaml 

clusterrole "nfs-client-provisioner-runner" created 

$ kubectl create -f deploy/auth/clusterrolebinding.yaml 
clusterrolebinding "run-nfs-client-provisioner" created 

$ kubectl patch deployment nfs-client-provisioner -p '{"spec":{" 
template": {"spec": {"serviceAccount":"nfs-client-provisioner"}}}}' 


— —————Á um] gu] 


测试 
测试 创建 PVC 

e kubectl create -f deploy/test-claim.yaml 
测试 创建 POD 

e kubectl create -f deploy/test-pod.yaml 


在 NFS 服 务 器 上 的 共享 目录 下 的 卷子 目录 中 检查 创建 的 NFS PV 卷 下 是 否 
有 "SUCCESS" 文 件 


删除 测试 POD 

e kubectl delete -f deploy/test-pod.yaml 
删除 测试 PVC 

e kubectl delete -f deploy/test-claim.yaml 


在 NFS 服 务 器 上 的 共享 目录 下 查看 NFS 的 PV 卷 回收 以 后 是 否 名 字 以 archived 开 头 。 


我 的 示例 
e NFS 服 务 器 配置 


# cat /etc/exports 


/media/docker *(no_root_squash, rw, sync, no_subtree_che 
ck) 


e nfs-deployment.yaml:s 4] 


NFS 服 务 器 的 地 址 是 ubuntu-master, 共享 出 来 的 路 径 是 /media/docker， 其 他 不 需要 
修改 。 


# cat nfs-deployment.yaml 


kind: Deployment 
apiVersion: extensions/vibetai 
metadata: 
name: nfs-client-provisioner 
spec: 
replicas: 1 
strategy: 
type: Recreate 
template: 
metadata: 
labels: 
app: nfs-client-provisioner 
spec: 
serviceAccountName: nfs-client-provisioner 
containers: 
- name: nfs-client-provisioner 
image: quay.io/external storage/nfs-client-provisioner: 
latest 
volumeMounts: 
- name: nfs-client-root 
mountPath: /persistentvolumes 
env: 
- name: PROVISIONER NAME 
value: fuseim.pri/ifs 
- name: NFS SERVER 
value: ubuntu-master 
- name: NFS PATH 
value: /media/docker 
volumes: 
- name: nfs-client-root 
ATS: 
server: ubuntu-master 
path: /media/docker 


| 
e StorageClass 示 例 


可 以 修改 Class 的 名 字 ， 我 的 改 成 了 default 。 


# cat class.yaml 


apiVersion: storage.k8s.io/vi 
kind: StorageClass 
metadata: 
name: default 
provisioner: fuseim.pri/ifs 


e 查看 StorageClass 


# kubectl get sc 
NAME PROVISIONER AGE 
default fuseim.pri/ifs 2d 


e it & 3X default £ F 4) SC A Kubernetes 49 RUG fi JE 38 


# kubectl patch storageclass default -p '("metadata": ("annotati 
ons":("storageclass.kubernetes.io/is-default-class":"true"3)J' 
storageclass.storage.k8s.io "default" patched 

# kubectl get sc 

NAME PROVISIONER AGE 

default (default) fuseim.pri/ifs 2d 


e 测试 创建 PVC 


查看 pvc 文 件 


# cat test-claim.yaml 


kind: PersistentVolumeClaim 
apiVersion: v1 
metadata: 
name: test-claim 
spec: 
accessModes: 
- ReadwriteMany 
resources: 
requests: 
storage: 1Mi 


创建 PVC 


# kubectl apply -f test-claim. yaml 
persistentvolumeclaim "test-claim" created 
root@Ubuntu-master:~/kubernetes/nfs# kubectl get pvc|grep test 


test-claim Bound pvc -fe3cb938-3f15-11e8-b61 
d-08002795cb26 1Mi RWX default 10s 
# kubectl get pv|grep test 
pvc-fe3cb938-3f15-11e8-b61d-08002795cb26 1Mi RWX 

Delete Bound default/test-claim 


default 58s 


e 启动 测试 POD 


POD 文 件 如 下 ， 作 用 就 是 在 test-claim 的 PV 里 touch 一 个 SUCCESS 文 件 。 


# cat test-pod.yaml 


kind: Pod 
apiVersion: v1 
metadata: 
name: test-pod 
spec: 
containers: 
- name: test-pod 
image: gcr.io/google containers/busybox:1.24 
command: 
- "/bin/sh" 
args: 
_ LIE oa 
- "touch /mnt/SUCCESS && exit O || exit 1" 
volumeMounts: 
- name: nfs-pvc 
mountPath: "/mnt" 
restartPolicy: "Never" 
volumes: 
- name: nfs-pvc 
persistentVolumeClaim: 
claimName: test-claim 


È POD * —Z/LPOD# completed & > HARTZE ° 


# kubectl apply -f test-pod.yaml 

pod "test-pod" created 

kubectl get pod|grep test 

test-pod 0/1 
Completed 0 40s 


我 们 去 NFS 共 享 目录 查看 有 没有 SUCCESS 文 件 。 


# cd default-test-claim-pvc-fe3cb938-3f15-11e8-b61d-08002795cb26 
# Is 
SUCCESS 


说 明 部 署 正 常 ， 并 且 可 以 动态 分 配 NFS 的 共享 卷 。 
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Kubernetes 使 得 管理 复杂 环境 变 得 更 简单 ， 但 是 对 kubernetes 本 身 的 各 种 组 件 还 
有 运行 在 kubernetes ee 用 程序 做 到 很 好 的 洞察 就 很 难 了 。 


Kubernetes 本 身 对 应 用 程序 的 做 了 很 多 抽象 ， 在 生产 环境 下 对 这 些 不 同 的 抽象 组 件 
的 健康 就 是 迫在眉睫 的 事情 。 


我 们 在 安装 kubernetes 集群 的 时 候 ， 默 认 安 装 了 kubernetes 官方 提供 的 heapster 
插件 ， 可 以 对 kubernetes 集群 上 的 应 用 进行 简单 的 监控 ， 获 取 pod 级 别 的 内 

存 、CPU 和 网 络 监 控 信 息 ， 同 时 还 能 够 通过 API 监控 kubernetes 中 的 基本 资源 监 
控 指标 。 

然而 ，Prometheus 的 出 现 让 人 眼前 一 亮 ， 与 kubernetes 一 样 同样 为 CNCF 中 的 
项 目 ， 而 且 是 第 一 个 加 入 到 CNCF 中 的 项 目 。 


Prometheus 是 由 SoundCloud 开源 监控 告警 解决 方案 ， 从 2012 年 开始 编写 代 
码 ， 再 到 2015 年 GitHub 上 开源 以 来 ， 已 经 吸引 了 Okt 关注 ， 以 及 很 多 大 公司 的 
使 用 ; 2016 年 Prometheus 成 为 继 k8s 后 ， 第 二 名 CNCF(Cloud Native 
Computing Foundation) 成 员 。 


作为 新 一 代 开 源 解决 方案 ， 很 多 理念 与 Google SRE 运 维 之 道 不 谋 而 合 。 
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Heapster 


Heapster 作 为 kubernetes 安 装 过 程 中 默认 安装 的 一 个 插件 ， 见 安装 heapster 插 件 。 
这 对 于 集群 监控 十 分 有 用 ， 同 时 在 Horizontal Pod Autoscaling 中 也 用 到 了 “，HPA 将 
Heapster 作 为 Resource Metrics API ， 向 其 获取 metric， 做 法 是 在 kube- 
controller-manager 中 配置 --api-server 指向 kube-aggregator， 也 可 以 使 用 
heapster 来 实现 ， 通 过 在 启动 heapster 的 时 候 指 定 --api-server=true 。 


Heapster 可 以 收集 Node 节 点 上 的 cAdvisor 数 据 ， 还 可 以 按照 kubernetes 的 资源 类 型 
来 集合 资源 ， 比 如 Pod、Namespace 域 ， 可 以 分 别 获取 它们 的 CPU、 内 存 、 网 络 和 
磁盘 的 metric。 上 默认 的 metric 数 据 有 聚合 时 间 间 隔 是 1 分 钟 。 
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Heapster 作 为 kubernetes 安 装 过 程 中 默认 安装 的 一 个 插件 ， 见 安装 heapster 插 件 。 
这 对 于 集群 监控 十 分 有 用 ， 同 时 在 Horizontal Pod Autoscaling 中 也 用 到 了 ，HPA 将 
Heapster 作 为 Resource Metrics API ， 向 其 获取 metric， 做 法 是 在 kube- 
controller-manager 中 配置 --api-server 指向 kube-aggregator， 也 可 以 使 用 
heapster 来 实现 ， 通 过 在 启动 heapster 的 时 候 指 定 --api-server=true 。 


Heapster 可 以 收集 Node 节 点 上 的 cAdvisor 数 据 ， 还 可 以 按照 kubernetes 的 资源 类 型 
来 集合 资源 ， 比 如 Pod、Namespace 域 ， 可 以 分 别 获取 它们 的 CPU、 内 存 、 网 络 和 
磁盘 的 metric。 默 认 的 metric 数 据 有 聚合 时 间 间 隔 是 1 分 钟 。 


ARI 


下 面 是 Heapster 架 构图 : 





Heapster 
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图 片 - Heapster 架 构图 


Heapser 是 用 Go 语言 开发 Kubernetes 集 群 计算 资源 使 用 情况 的 数据 采集 工具 ， 编 译 
后 可 以 直接 以 一 个 二 进 制 文件 运行 ， 通 过 向 heapster 传 递 的 参数 来 指定 数据 采集 行 
为 ， 这 些 数 据 可 以 选择 多 种 sink 方 式 ， 例 如 Graphite、influxDB、OpenTSDB、 


ElasticSearch ` Kafka ° 
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Heapster 使 用 起 来 很 简单 ， 本 身 就 是 二 进 制 文件 ， 直 接 使 用 命令 行 启动 ， 也 可 以 放 
在 容器 里 运行 ， 在 作为 kubernetes 插 件 运行 时 ， ne ee 容器 中 的 ， 见 安装 


heapster 插 件 。 


运行 


下 面 是 heapster 的 局 


Flag 


--allowed- 
users string 


alsologtostderr 
--api-server 


authentication- 
kubeconfig 
string 


authentication- 
token- 
webhook- 
cache-ttl 
duration 


--authorization- 
kubeconfig 
string 


--authorization- 
webhook- 
cache- 
authorized-ttl 
duration 


--authorization- 


动 参数 : 


Description 


comma-separated list of allowed users 


log to standard error as well as files 


Enable API server for the Metrics API. If set, the Metrics 
API will be served on --insecure-port (internally) and -- 
secure-port (externally). 


kubeconfig file pointing at the 'core' kubernetes server with 
enough rights to create 
tokenaccessreviews.authentication.k8s.io. 


The duration to cache responses from the webhook token 
authenticator. (default 10s) 


kubeconfig file pointing at the 'core' kubernetes server with 
enough rights to create 
subjectaccessreviews.authorization.k8s.io. 


The duration to cache ‘authorized’ responses from the 
webhook authorizer. (default 10s) 


webhook- 
cache- 
unauthorized- 
ttl duration 


--bind-address 
ip 


--cert-dir string 


--client-ca-file 
string 


--contention- 
profiling 


--disable- 
export 


--enable- 
swagger-ui 


--heapster-port 
int 


--historical- 
source string 


--label- 
seperator 
string 


--listen-ip 
string 


--log- 
backtrace-at 
traceLocation 


--log-dir string 


--log-flush- 
frequency 
duration 


The duration to cache ‘unauthorized’ responses from the 
webhook authorizer. (default 10s) 


The IP address on which to listen for the --secure-port port. 
The associated interface(s) must be reachable by the rest 
of the cluster, and by CLI/web clients. If blank, all interfaces 
will be used (0.0.0.0). (default 0.0.0.0) 


The directory where the TLS certs are located (by default 
/var/run/kubernetes). If --tls-cert-file and --tls-private-key-file 
are provided, this flag will be ignored. (default 
"/var/run/kubernetes") 


If set, any request presenting a client certificate signed by 
one of the authorities in the client-ca-file is authenticated 
with an identity corresponding to the CommonName of the 
client certificate. 


Enable contention profiling. Requires --profiling to be set to 
work. 


Disable exporting metrics in api/v1/metric-export 


Enables swagger ui on the apiserver at /swagger-ui 


port used by the Heapster-specific APIs (default 8082) 


which source type to use for the historical API (should be 
exactly the same as one of the sink URIs), or empty to 
disable the historical API 


seperator used for joining labels (default ",") 


IP to listen on, defaults to all IPs 


when logging hits line file:N, emit a stack trace (default :0) 


If non-empty, write log files in this directory 


Maximum number of seconds between log flushes (default 
5s) 


--logtostderr 
--max-procs int 


--metric- 
resolution 
duration 


--profiling 


requestheader- 
allowed-names 
stringSlice 


requestheader- 
client-ca-file 
string 


requestheader- 
extra-headers- 
prefix 
stringSlice 


requestheader- 
group-headers 
stringSlice 


requestheader- 
username- 
headers 
stringSlice 


--secure-port 
int 

--sink 
*flags.Uris 


--source 
*flags.Uris 


stderrthreshold 
severity 


log to standard error instead of files (default true) 


max number of CPUs that can be used simultaneously. 
Less than 1 for default (number of cores) 


The resolution at which heapster will retain metrics. (default 
1mOs) 


Enable profiling via web interface host:port/debug/pprof/ 
(default true) 


List of client certificate common names to allow to provide 
usernames in headers specified by --requestheader- 
username-headers. If empty, any client certificate validated 
by the authorities in --requestheader-client-ca-file is 
allowed. 


Root certificate bundle to use to verify client certificates on 
incoming requests before trusting usernames in headers 
specified by --requestheader-username-headers 


List of request header prefixes to inspect. X-Remote-Extra- 
is suggested. (default [x-remote-extra-]) 


List of request headers to inspect for groups. X-Remote- 
Group is suggested. (default [x-remote-group]) 


List of request headers to inspect for usernames. X- 
Remote-User is common. (default [x-remote-user]) 


The port on which to serve HTTPS with authentication and 
authorization. If 0, don't serve HTTPS at all. (default 6443) 


external sink(s) that receive data (default []) 


source(s) to watch (default []) 


logs at or above this threshold go to stderr (default 2) 


--tls-ca-file 
string 


--tls-cert string 


--tls-cert-file 
string 


--tls-client-ca 
string 


--tls-key string 


--tls-private- 
key-file string 


--tls-sni-cert- 
key 


namedCertKey 


--v Level 
--version 
--vmodule 
moduleSpec 


Version 


If set, this certificate authority will used for secure access 
from Admission Controllers. This must be a valid PEM- 
encoded CA bundle. Altneratively, the certificate authority 
can be appended to the certificate provided by --tls-cert-file. 


file containing TLS certificate 


File containing the default x509 Certificate for HTTPS. (CA 
cert, if any, concatenated after server cert). If HTTPS 
serving is enabled, and --tls-cert-file and --tls-private-key-file 
are not provided, a self-signed certificate and key are 
generated for the public address and saved to 
/var/run/kubernetes. 


file containing TLS client CA for client cert validation 


file containing TLS key 


File containing the default x509 private key matching --tls- 
cert-file. 


A pair of x509 certificate and private key file paths, 
optionally suffixed with a list of domain patterns which are 
fully qualified domain names, possibly with prefixed 
wildcard segments. If no domain patterns are provided, the 
names of the certificate are extracted. Non-wildcard 
matches trump over wildcard matches, explicit domain 
patterns trump over extracted names. For multiple 
key/certificate pairs, use the --tls-sni-cert-key multiple times. 
Examples: "example.key,example.crt" or 

"* foo.com,foo.com:foo.key,foo.crt". (default []) 


log level for V logs 
print version info and exit 


comma-separated list of pattern=N settings for file-filtered 
logging 


version: v1.4.0 commit: 546ab66f 


APH Jf] 


Heapsterdt RESTful API 接 口 ， 下 面 以 获取 spark-cluster namespace 
memory usage 为 例 讲解 Heapster API 的 使 用 。 


构造 URL 地 址 


https://172.20.0.113:6443/api/v1/proxy/namespaces/kube- 
system/services/heapster/api/v1/model/namespaces/spark- 
cluster/metrics/memory/usage?start=201 7-10-16T09:14:00Z&end=201 7-10- 
16T09:16:00Z 


结果 


访问 该 地 址 获取 的 结果 是 这 样 的 : 


"metrics": [ 


"timestamp": "2017-10-16T09:14:00Z", 
"value": 322592768 


3 

{ 
"timestamp": "2017-10-16T09:15:00Z", 
"value": 322592768 


3 

{ 
"timestamp": "2017-10-16T09:16:00Z", 
"value": 322592768 


], 
"latestTimestamp": "2017-10-16T09:16:00Z" 


} 
注意 : Heapster 中 查询 的 所 有 值 都 是 以 最 小 单位 为 单位 ， 比 如 CPU 为 1milicore， 内 
4 XB 
第 一 部 分 : Heapster API 地 址 


https://172.20.0.113:6443/api/v1/proxy/namespaces/kube- 
system/services/heapster/ 


可 以 使 用 下 面 的 命令 获取 : 


$ kubectl cluster-info 
Heapster is running at https://172.20.0.113:6443/api/vi/proxy/na 
mespaces/kube-system/services/heapster 


Je 


第 二 部 分 : Heapster APIA X 


/api/vi/model/namespaces/spark-cluster/metrics/memory/usage 

表示 查询 的 是 spark-cluster namespace ¥ 4 memory/usage metrics ° 

第 三 部 分 : 时 间 片 

?start-2017-10-16T09:14:00Z&end-2017-10-16T09:16:00Z 

查询 参数 为 时 间 片 : 包括 start 和 end。 使 用 RFC-3339 时 间 格 式 ， 在 Linux 系 统 中 可 


以 这 样 获取 : 


$ date --rfc-3339="seconds" 
2017-10-16 17:23:20+08:00 


该 时 间 中 的 空格 蔡 换 成 T， 最 后 的 +08:00 替换 成 Z 代 表 时 区 。 可 以 只 指定 start 时 
间 ，end 时 间 自 动 设置 为 当前 时 间 。 


参考 


e kubernetes metrics 
e Heapster metric model 
e Heapster storage schema 
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Prometheus 


Prometheus 是 由 SoundCloud 开源 监控 告警 解决 方案 ， 从 2012 年 开始 编写 代 

码 ， 再 到 2015 年 github 上 开源 以 来 ， 已 经 吸引 了 Okt 关注 ， 以 及 很 多 大 公司 的 使 
用 ; 2016 年 Prometheus 成 为 继 k8s 后 ， 第 二 名 CNCF(Cloud Native Computing 
Foundation) 成 员 。 


作为 新 一 代 开源 解决 方案 ， 很 多 理念 与 Google SRE 运 维 之 道 不 谋 而 合 。 


主要 功能 


e 多 维 数据 模型 (时序 由 metric 名 字 和 k/v 的 labels 构成 ) ° 
e 灵活 的 查询 语句 (PromQL) » 

e 无 依赖 存储 ， 支 持 local 和 remote 不 同 模型 。 

e. 采用 http 协议 ， 使 用 pull 模式 ， 拉 取 数 据 ， 简 单 易 懂 。 

e 监控 目标 ， 可 以 采用 服务 发 现 或 静态 配置 的 方式 。 

e 支持 多 种 统计 数据 模型 ， 图 形 化 友好 。 


核心 组 件 


e Prometheus Server， 主 要 用 于 抓 取 数据 和 存储 时 序数 据 ， 另 外 还 提供 查询 和 
Alert Rule 配置 管理 。 

e client libraries， 用 于 对 接 Prometheus Server, 可 以 查询 和 上 报 数 据 。 

e push gateway ， 用 于 批量 ， 短 期 的 监控 数据 的 汇总 节点 ， 主 要 用 于 业务 数据 

汇报 等 。 

各 种 汇报 数据 的 exporters ， 例 如 汇报 机 器 数据 的 node_exporter, 汇报 

MongoDB 信息 的 MongoDB exporter 等 等 。 

e 用 于 告警 通知 管理 的 alertmanager 。 


基础 架构 


一 图 胜 千 言 ， 先 来 张 官 方 的 架构 图 : 
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图 片 - Prometheus 架构 图 


从 这 个 架构 图 ， 也 可 以 看 出 Prometheus 的 主要 模块 包含 ， Server, Exporters, 


Pushgateway, PromQL, Alertmanager, WebUI = 
它 大 致使 用 逻辑 是 这 样 : 


1. Prometheus server 定期 从 静态 配置 的 targets 或 者 服务 发 现 的 targets 拉 取 数 
据 。 

2. 当 新 拉 取 的 数据 大 于 配置 内 存 缓存 区 的 时 候 ，Prometheus 会 将 数据 持久 化 到 
磁盘 (如果 使 用 remote storage 将 持久 化 到 云端 ) o 

3. Prometheus 可 以 配置 rules， 然 后 定时 查询 数据 ， 当 条 件 触发 的 时 候 ， 会 将 
alert 推送 到 配置 的 Alertmanager ° 

4. Alertmanager 收 到 警告 的 时 候 ， 可 以 根据 配置 ， 有 聚合 ， 去 重 ， 降 噪 ， 最 后 发 送 


5. 可 以 使 用 API * Prometheus Console 或 者 Grafana 查询 和 聚合 数据 。 


" 


e Prometheus 的 数据 是 基于 时 序 的 float64 的 值 ， 如果 你 的 数据 值 有 更 多 类 型 ， 
无 法 满足 。 

e Prometheus 不 适合 做 审计 计 费 ， 因 为 它 的 数据 是 按 一 定时 间 采 集 的 ， 关 注 的 
更 多 是 系统 的 运行 瞬时 状态 以 及 趋势 ， 即 使 有 少量 数据 没有 采集 也 能 容忍 ， 但 
是 审计 计 费 需要 记录 每 个 请 求 ， 并 且 数 据 长 期 存储 ， 这 个 和 Prometheus 无 法 
满足 ， 可 能 需要 采用 专门 的 审计 系统 。 


以 上 介绍 来 自 https://github.com/songjiayang/prometheus_practice/ 
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我 们 使 用 Giantswarm 开源 的 kubernetes-promethues 来 监控 kubernetes 集群 ， 
所 有 的 YAML 文件 可 以 在 .Jmanifests/prometheus 目录 下 找到 。 


需要 用 到 的 镜像 有 : 


e harbor-001.jimmysong.io/library/prometheus-alertmanager:vO.7 .1 
e harbor-001.jimmysong.io/library/grafana:4.2.0 

e harbor-001.jimmysong.io/library/giantswarm-tiny-tools:latest 

e harbor-001 .jimmysong.io/library/prom-prometheus:v1.7.0 

e harbor-001 .jimmysong.io/library/kube-state-metrics:v1.0.1 

e harbor-001.jimmysong.io/library/dockermuenster-caddy:0.9.3 

e harbor-001.jimmysong.io/library/prom-node-exporter:vO. 14.0 


同时 备份 到 时 速 云 : 


e index.tenxcloud.com/jimmy/prometheus-alertmanager:vO.7 .1 
e index.tenxcloud.com/jimmy/grafana:4.2.0 

e index.tenxcloud.com/jimmy/giantswarm-tiny-tools:latest 

e index.tenxcloud.com/jimmy/prom-prometheus:v1.7.0 

e index.tenxcloud.com/jimmy/kube-state-metrics:v 1.0.1 

e index.tenxcloud.com/jimmy/dockermuenster-caddy:0.9.3 

e index.tenxcloud.com/jimmy/prom-node-exporter:vO. 14.0 


注 : 所 有 镜像 都 是 从 官方 镜像 仓库 下 载 下 。 
ME 


我 将 部 署 时 需要 用 的 的 配置 文件 分 成 了 namespace ` serviceaccount ` 
configmaps ^ clusterrolebinding 和 最 后 的 部 署 prometheus ` grafana 的 过 程 。 


kubectl create -f prometheus-monitoring-ns.yaml 

kubectl create -f prometheus-monitoring-serviceaccount.yaml 
kubectl create -f prometheus-configmaps.yaml 

kubectl create clusterrolebinding kube-state-metrics --clusterro 
le=cluster-admin --serviceaccount=monitoring: kube-state-metrics 
kubectl create clusterrolebinding prometheus --clusterrole=clust 


er-admin --serviceaccount=monitoring: prometheus 


kubectl create -f prometheus-monitoring. yaml 


访问 kubernetes 任何 一 个 node 上 的 Grafana service 的 nodeport : 





图 片 - Grafana 页 面 


该 图 中 的 数据 显示 明显 有 问题 ， 还 需要 修正 。 


SCLIN USO I yaml 文件 中 有 一 个 Job 就 是 用 来 导入 grafana 
dashboard 配置 信息 的 ， 如 果 该 Job 执行 失败 ， 可 以 单独 在 在 monitoring 的 


namespace 中 局 动 一 个 容器 ， 将 和 目录 下 的 json 文件 复 
制 到 容器 中 ， 然 后 进入 容器 json 文件 的 目录 下 执行 


for file in *-datasource.json ; do 
if [ -e "$file" ] ; then 
echo "importing $file" && 
curl --silent --fail --show-error \ 
--request POST http://admin:admin@grafana: 3000 
/api/datasources \ 
--header "Content-Type: application/json" \ 
--data-binary "@$file" ; 
echo wi ; 
Ti 
done ; 
for file in *-dashboard.json ; do 
if [ -e "$file" ] ; then 
echo "importing $file" && 
( echo '{"dashboard":'; \ 
cat "$file"; \ 
echo ', "overwrite": true, "inputs": [{"name": "DS __ 
PROMETHEUS", "type": "datasource", "pluginId":"prometheus", "value": 
"prometheus"}]}' ) N 
| jq -c '.' \ 
| curl --silent --fail --show-error \ 
--request POST http://admin:admin@grafana: 3000 
/api/dashboards/import \ 
--header "Content-Type: application/json" \ 
--data-binary "@-" ; 
echo "" : 
Fi 
done 


这 样 也 可 以 向 grafana 中 导入 dashboard ° 


存在 的 问题 


该 项 目的 代码 中 存在 几 个 问题 。 


1. RBAC 角色 授权 问题 


需要 用 到 两 个 clusterrolebinding : 


e kube-state-metrics ， 对 应 的 serviceaccount 是 kube-state- 
metrics 


e prometheus ， 对 应 的 serviceaccount Æ prometheus-k8s 


在 部 署 Prometheus 之 前 应 该 先 创 建 serviceaccount ` clusterrole ^ 
clusterrolebinding 等 对 象 ， 和 否则 在 安装 过 程 中 可 能 因为 权限 问题 而 导致 各 种 错误 ， 
所 以 这 些 配置 应 该 写 在 一 个 单独 的 文件 中 ， 而 不 应 该 跟 其 他 部 署 写 在 一 起 ， 即 使 要 
写 在 一 个 文件 中 ， 也 应 该 写 在 文件 的 最 前 面 ， 因 为 使 用 kubectl 部 署 的 时 候 ， 
kubectl 不 会 判断 YAML 文件 中 的 资源 依赖 关系 ， 只 是 简单 的 从 头 部 开始 执行 部 
署 ， 因 此 写 在 文件 前 面 的 对 象 会 先 部 署 。 


解决 方法 


也 可 以 绕 过 复杂 的 RBAC 设置 ， 直 接 使 用 下 面 的 命令 将 对 应 的 serviceaccount 设 
置 成 admin 权限， 如 下 : 


kubectl create clusterrolebinding kube-state-metrics --clusterro 
le-cluster-admin --serviceaccount=monitoring: kube-state-metrics 

kubectl create clusterrolebinding prometheus --clusterrole=clust 
er-admin --serviceaccount-monitoring:prometheus 


参考 RBAC 一 一 基于 角色 的 访问 控制 


2. API 兼容 问题 


从 kube-state-metrics 日 志 中 可 以 看 出 用 户 kube-state-metrics 没有 权限 访问 
如 下 资源 类 型 : 


e *v1.Job 

e *v1.PersistentVolumeClaim 
e *vibeta1.StatefulSet 

e *v2alpha1.CronJob 


而 在 我 们 使 用 的 kubernetes 1.6.0 版 本 的 集群 中 API 路 径 跟 kube-state- 
metrics PRA > Æ list 以 上 三 种 资源 对 象 的 资源 。 详 情 
JL : https://github.com/giantswarm/kubernetes-prometheus/issues/77 


3. Job 中 的 权限 认证 问题 


在 grafana-import-dashboards 这 个 job 中 有 个 init-containers 其 中 指 
定 的 command 执行 错误 ， 应 该 使 用 


curl -sX GET -H "Authorization:bearer ‘cat /var/run/secrets/kube 
rnetes.io/serviceaccount/token' " -k https://kubernetes.default/a 
pi/vi/namespaces/monitoring/endpoints/grafana 


不 需要 指定 csr 文件 ， 只 需要 token 即 可 。 


参考 wait-for-endpoints init-containers fails to load with k8s 1.6.0 #56 


e Kubernetes Setup for Prometheus and Grafana 
e RBAC 一 一 基于 角色 的 访问 控制 
e wait-for-endpoints init-containers fails to load with k8s 1.6.0 #56 
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服务 编排 管理 


Kubernetes 虽 然 提 供 了 多 种 容器 编排 对 象 ， 例 如 Deployment、StatefulSet、 
DeamonSet、Job 等 ， 还 有 多 种 基础 资源 封装 例如 ConfigMap、Secret、Serivce 
等 ， 但 是 一 个 应 用 往往 有 多 个 服务 ， 有 的 可 能 还 要 依赖 持久 化 存储 ， 当 这 些 服 务 之 
间 直 接 互相 依赖 ， 需 要 有 一 定 的 组 合 的 情况 下 ， 使 用 YAML 文 件 的 方式 配置 应 用 往 
往 十 分 繁琐 还 容易 出 错 ， 这 时 候 就 需要 服务 编排 工具 。 


服务 编排 管理 工具 就 是 构建 在 kubernetes 的 基础 object 之 上 ， 统 筹 各 个 服务 之 间 的 
关系 和 依赖 的 。 目 前 常用 到 的 工具 是 Helm 。 
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1$ | Helm € 22 kubernetes ~ M 


读 完 本 文 后 您 应 该 可 以 自己 创建 chart， 并 创建 自己 的 私有 chart 仓 库 。 


Helm 是 一 个 kubernetes 应 用 的 包 管理 工具 ， 用 来 管理 charts 一 一 预先 配置 好 的 安装 
包 资 源 ， 有 点 类 似 于 Ubuntu 的 APT 和 CentOS 中 的 yum ° 


Helm chart 是 用 来 封装 Kubernetes 原 生 应 用 程序 的 yaml 文 件 ， 可 以 在 你 部 署 应 用 的 
时 候 自 定义 应 用 程序 的 一 些 metadata， 便 与 应 用 程序 的 分 发 。 


Helm 和 charts 的 主要 作用 : 


e [m 序 封装 

e 版 本 管理 

o 依赖 检查 

e 便于 应 用 程序 分 发 


安装 Helm 


前 提要 求 


e Kubernetes1.5 以 上 版 本 
。 集群 可 访问 到 的 镜像 仓库 
e 执行 helm 命 令 的 主机 可 以 访问 到 kubernetes 集 群 


安装 步骤 
首先 需要 安装 helm 客 户 端 


curl https://raw.githubusercontent.com/kubernetes/helm/master/sc 
ripts/get » get helm.sh 

chmod 700 get helm.sh 

./get helm.sh 


创建 tiller 的 serviceaccount 和 clusterrolebinding 


kubectl create serviceaccount --namespace kube-system tiller 
kubectl create clusterrolebinding tiller-cluster-rule --clusterr 
ole=cluster-admin --serviceaccount=kube-system: tiller 


然后 安装 helIm 服 务 端 tiller 


helm init -i jimmysong/kubernetes-helm-tiller:v2.8.1 


(目前 最 新 版 v2.8.2， 可 以 使 用 阿里 云 镜 像 ， 如 : helm init --upgrade -i registry.cn- 
hangzhou.aliyuncs.com/google_containers/tiller:v2.8.2 --stable-repo-url 
https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts ) 


我 们 使 用 -i 指定 自己 的 镜像 ， 因 为 官方 的 镜像 因为 某 些 原因 无 法 拉 取 ， 官 方 镜 像 
地 址 是 : gcr.io/kubernetes-helm/tiller:v2.8.1 ， 我 在 DockerHub 上 放 了 一 
个 备份 jimmysong/kubernetes-helm-tiller:v2.8.1 ， 该 镜像 的 版 本 与 helm 客 
户 端的 版 本 相同 ， 使 用 helm version 可 查看 helm 客 户 端 版 本 。 


为 应 用 程序 设置 serviceAccount 


kubectl patch deploy --namespace kube-system tiller-deploy -p 'f{ 
"spec": {"template":{"spec":{"serviceAccount":"tiller"}}}}' 


$ kubectl -n kube-system get pods|grep tiller 
tiller -deploy -2372561459- f6p0z 1/1 Running 0 
1h 
$ helm version 
Client: &version.Version{SemVer: "v2.3.1", GitCommit:"32562a3040b 
b5ca690339b9840b6f60f8ce25da4", GitTreeState:"clean"} 
Server: &version.Version(SemVer:"v2.3.1", GitCommit:"32562a3040b 
b5ca690339b9840b6f60f8ce25da4", GitTreeState:"clean"} 


创建 自己 的 chart 


我 们 创建 一 个 名 为 mychart 的 chart， 看 一 看 chart 的 文件 结构 。 


$ helm create mongodb 

$ tree mongodb 

mongodb 

| 一 Chart.yaml #Chart 本 身 的 版 本 和 配置 信息 

I— charts # 依 赖 的 chart 

I — templates ## 配 置 模板 目录 

| | F— NOTES.txt #helm 提 示 信息 

| | 一 _helpers.tpl #4 Tff kubernetes objcet 配 置 的 模板 
| I— deployment.yaml #kubernetes Deployment object 
| L— service.yaml #kubernetes Serivce 

L— values.yaml #kubernetes object configuration 


2 directories, 6 files 


模板 


Templates 目录 下 是 yaml 文 件 的 模板 ， 遵 循 Go template?& zk » 4% f] it Hugo f 8$ 
态 网 站 生成 工具 的 人 应 该 对 此 很 熟悉 。 


我 们 查看 下 deployment.yaml 文件 的 内 容 。 


apiVersion: extensions/vibeta1 
kind: Deployment 
metadata: 
name: {{ template "fullname" . }} 
labels: 
chart: "{{ .Chart.Name }}-{{ .Chart.Version | replace "+" " 
" }}" 


spec: 
replicas: {{ .Values.replicaCount }} 
template: 
metadata: 
labels: 
app: {{ template "fullname" . }} 
spec: 
containers: 
- name: {{ .Chart.Name }} 
image: "{{ .Values.image.repository }}:{{ .Values.image. 
tag }}" 
imagePullPolicy: {{ .Values.image.pullPolicy }} 
ports: 
- containerPort: {{ .Values.service.internalPort }} 
livenessProbe: 
httpGet: 
path: / 
port: {{ .Values.service.internalPort }} 
readinessProbe: 
httpGet: 
path: / 
port: {{ .Values.service.internalPort }} 
resources: 


{{ toyaml .Values.resources | indent 12 }} 


这 是 该 应 用 的 Deployment 的 yaml 配 置 文件 ， 其 中 的 双 大 括号 包 扩 起 来 的 部 分 是 Go 
template， 其 中 的 Values 是 在 values.yaml 文件 中 定义 的 : 


# Default values for mychart. 

# This is a yaml-formatted file. 

# Declare variables to be passed into your templates 
replicaCount: 1 


image: 

repository: nginx 

tag: stable 

pullPolicy: IfNotPresent 
service: 


name: nginx 
type: ClusterIP 
externalPort: 80 
internalPort: 80 


resources: 
Lum 
cpu: 100m 
memory: 128Mi 
requests: 
cou: 100m 


memory: 128Mi 


比如 在 Deployment.yaml 中 定义 的 容器 镜像 image: "{{ 
.Values.image.repository }}:{{ .Values.image.tag }}" 其 中 的 : 


e .Values.image.repository 就 是 nginx 
e .Values.image.tag 就 是 stable 


以 上 两 个 变量 值 是 在 create chart 的 时 候 自 动 生成 的 默认 值 。 


我 们 将 默认 的 镜像 地 址 和 tag 改 成 我 们 自己 的 镜像 harbor- 
001.jimmysong.io/library/nginx:1.9 ° 


检查 配置 和 模板 是 否 有 效 


当 使 用 kubernetes 部 署 应 用 的 时 候 实际 上 讲 templates 演 染 成 最 终 的 kubernetes 能 够 
识别 的 yaml 格 式 。 


使 用 helm install --dry-run --debug «chart dir» 命令 来 验证 chart 配 置 。 
该 输出 中 包含 了 模板 的 变量 配置 与 最 终 演 染 的 yam| 文 件 。 


$ helm install --dry-run --debug mychart 

Created tunnel using local port: '58406' 

SERVER: "localhost :58406" 

CHART PATH: /Users/jimmy/Workspace/github/bitnami/charts/incubat 
or/mean/charts/mychart 


NAME: filled-seahorse 

REVISION: 1 

RELEASED: Tue Oct 24 18:57:13 2017 
CHART: mychart-0.1.0 

USER-SUPPLIED VALUES: 


{} 


COMPUTED VALUES: 

image: 
pullPolicy: IfNotPresent 
repository: harbor-001.jimmysong.io/library/nginx 
tag: 1.9 

replicaCount: 1 


resources: 
limits: 
cpu: 100m 
memory: 128Mi 
requests: 
cpu: 100m 
memory: 128Mi 
service: 


externalPort: 80 
internalPort: 80 
name: nginx 

type: ClusterIP 


HOOKS: 
MANIFEST: 


# Source: mychart/templates/service.yaml 
apiVersion: vi 
kind: Service 
metadata: 
name: filled-seahorse-mychart 
labels: 
chart: "mychart-0.1.0" 
spec: 
type: ClusterIP 
ports: 
- port: 80 
targetPort: 80 
protocol: TCP 
name: nginx 
selector: 
app: filled-seahorse-mychart 


# Source: mychart/templates/deployment.yaml 
apiVersion: extensions/vibetai 
kind: Deployment 
metadata: 
name: filled-seahorse-mychart 


labels: 
chart: "mychart-0.1.0" 
spec: 
replicas: 1 
template: 
metadata: 
labels: 
app: filled-seahorse-mychart 
spec: 
containers: 
- name: mychart 
image: "harbor-001.jimmysong.io/library/nginx:1.9" 
imagePullPolicy: IfNotPresent 
ports: 
- containerPort: 80 
livenessProbe: 
httpGet: 
path: / 
port: 80 
readinessProbe: 
httpGet: 
path: / 
port: 80 
resources: 
limits: 
cpu: 100m 
memory: 128Mi 
requests: 
cpu: 100m 
memory: 128Mi 


我 们 可 以 看 到 Deployment 和 Service 的 名 字 前 半截 由 两 个 随机 的 单词 组 成 ， 最 后 才 
是 我 们 在 values.yaml 中 配置 的 值 。 


部 署 到 kubernetes 


在 mychart 目录 下 执行 下 面 的 命令 将 nginx 部 署 到 kubernetes 集 群 上 。 


helm install . 

NAME : eating-hound 

LAST DEPLOYED: Wed Oct 25 14:58:15 2017 
NAMESPACE: default 

STATUS: DEPLOYED 


RESOURCES: 

==> vi/Service 

NAME CLUSTER- IP EXTERNAL-IP  PORT(S) AGE 
eating-hound-mychart 10.254.135.68 <none> 80/TCP Os 
==> extensions/vibeta1/Deployment 

NAME DESIRED CURRENT UP-TO-DATE AVAILABLE A 
GE 

eating-hound-mychart 1 1 1 0 0 
S 

NOTES: 


1. Get the application URL by running these commands: 
export POD NAME-$(kubectl get pods --namespace default -1 "app 
-eating-hound-mychart" -o jsonpath="{.items[0].metadata.name}") 
echo "Visit http://127.0.0.1:8080 to use your application" 
kubectl port-forward $POD NAME 8080:80 


现在 nginx 已 经 部 署 到 kubernetes 集 群 上 ， 本 地 执行 提示 中 的 命令 在 本 地 主机 上 访问 
到 nginx 实 例 。 


export POD_NAME=$(kubectl get pods --namespace default -1 "app=e 
ating-hound-mychart" -o jsonpath="{.items[0].metadata.name}") 
echo "Visit http://127.0.0.1:8080 to use your application" 
kubectl port-forward $POD_NAME 8080:80 


在 本 地 访问 http://127.0.0.1:8080 即 可 访问 到 nginx ° 


查看 部 署 的 relaese 


$ helm list 

NAME REVISION UPDATED STATUS 
CHART NAMESPACE 

eating-hound 1 Wed Oct 25 14:58:15 2017 DEPLOYED 


mychart-0.1.0 default 


删除 部 署 的 release 


$ helm delete eating-hound 
release "eating-hound" deleted 


打包 分 享 


我 们 可 以 修改 Chart.yaml 中 的 helm chart 配 置信 息 ， 然 后 使 用 下 列 命令 将 chart 打 
包 成 一 个 压缩 文件 。 


helm package . 


打包 出 mychart-0.1.0.tgz 文件 。 


依赖 


我 们 可 以 在 requirement.yaml 中 定义 应 用 所 依赖 的 chart， 例 如 定义 
对 mariadb 的 依赖 : 


dependencies: 
- name: mariadb 
version: 0.6.0 
repository: https://kubernetes-charts.storage.googleapis.com 


使 用 helm lint . 命令 可 以 检查 依赖 和 模板 配置 是 否 正 确 。 


安装 源 
# 
使 用 第 三 方 chat 库 


。 添加 fabric8 库 


$helm repo add fabric8 https://fabric8.io/helm 


。 搜 索 fabric8 提 供 的 工具 (主要 就 是 fabric8-platform 工 具 包 ， 包 含 了 Cl,CD 的 全 套 
工具 ) 


$helm search fabric8 


T 


我 们 在 前 面 安装 chart 可 以 通过 HTTP server 的 方式 提供 。 


$ helm serve 
Regenerating index. This may take a moment. 
Now serving you on 127.0.0.1:8879 


访问 http://localhost:8879 可 以 看 到 刚刚 安装 的 chart » 


€ Q € |Qlocalhost:8879 


Helm Charts Repository 


e mychart 
o mychart-0.1.0 


Last Generated: 2017-10-25 15:19:14.920637 +0800 CST 


& A - Helm chart? 


点 击 链接 即 可 以 下 载 chart 的 压缩 包 。 


注意 事项 


下 面 列 举 一 些 常见 问题 ， 和 在 解决 这 些 问 题 时 候 的 注意 事项 。 


服务 依赖 管理 


所 有 使 用 helm 部 署 的 应 用 中 如 果 没 有 特别 指定 chart 的 名 字 都 会 生成 一 个 随机 
的 Release name ， 例 如 romping-frog ^ sexy-newton 等 ， 跟 启动 docker 容 
器 时 候 容器 名 字 的 命名 规则 相同 ， 而 申 正 的 资源 对 象 的 名 字 是 在 YAML 文 件 中 定义 


na 


的 名 字 ， 我 们 成 为 App name ， 两 者 连接 起 来 才 是 资源 对 象 的 实际 名 


字 : Release name - App name ° 


而 使 用 helm chart 部 署 的 包含 依赖 关系 的 应 用 ， 都 会 使 用 同一 套 Release name * 
在 配置 YAML 文 件 的 时 候 一 定 要 注意 在 做 服务 发 现时 需要 配置 的 服务 地 址 ， 如 果 使 
用 环境 变量 的 话 ， 需 要 像 下 面 这 样 配 置 。 


env: 
- name: SERVICE_NAME 
value: "{{ .Release.Name }}-{{ .Values.image.env.SERVICE_NAME 


P3 du 


这 是 使 用 了 Go template 的 语法 。 至 于 {{ .values.image.env.SERVICE NAME 
}} 的 值 是 从 values.yaml 文件 中 获取 的 ， 所 以 需要 在 values.yaml 中 增加 如 
下 配置 : 


image: 
env: 
SERVICE NAME: k8s-app-monitor-test 


解决 本 地 chart 依 赖 


在 本 地 当前 chart 配 置 的 目录 下 启动 helm server， 我 们 不 指定 任何 和 参数， 直接 使 用 
默认 端口 启动 。 


helm serve 


将 该 repo 加 入 到 repo list? ° 


helm repo add local http://localhost :8879 


在 浏览 器 中 访问 http:Wlocalhost:8879 可 以 看 到 所 有 本 地 的 chart » 


然后 下 载 依赖 到 本 地 。 


helm dependency update 


这 样 所 有 的 chart 都 会 下 载 到 本 地 的 charts 目录 下 。 


i É£ helm? 4- E 25 3b 
为 了 方便 helm 命 令 的 使 用 ，helm 提 供 了 自动 补 全 功能 ， 如 果 使 用 zsh 请 执行 : 


source <(helm completion zsh) 


如 果 使 用 bash 请 执行 : 


source <(helm completion bash) 


3h MEAN 3E 49] 
MEAN 是 用 来 构建 网 站 和 web 应 用 的 免费 开源 的 JavaScript 软 件 栈 ， 该 软件 栈 包括 
MongoDB、Express.js、Angular 和 Node.js。 


下 载 charts 


$ git clone https://github.com/bitnami/charts.git 
$ cd charts/incubator/mean 
$ helm dep list 


NAME VERSION REPOSITORY 

STATUS 
mongodb 0.4.x https://kubernetes-charts.storage.googleap 
is.com/ missing 


缺少 mongodb 的 依赖 ， 需 要 更 新 一 下 chart。 


注 : https://kubernetes-charts.storage.googleapis.com/ 是 Google 维 护 
的 chart 库 ， 访 问 该 地 址 可 以 看 到 所 有 的 chart 列 表 。 


$ helm dep update 
Hang tight while we grab the latest from your chart repositories 


...Unable to get an update from the "local" chart repository (ht 
tp://127.0.0.1:8879/charts): 

Get http://127.0.0.1:8879/charts/index.yaml: dial tcp 127.0. 
0.1:8879: getsockopt: connection refused 
...Successfully got an update from the "stable" chart repository 
Update Complete. Happy Helming! * 
Saving 1 charts 
Downloading mongodb from repo https://kubernetes-charts.storage. 
googleapis.com/ 


所 有 的 image 都 在 values.yaml 文件 中 配置 。 


下 载 缺 失 的 chart。 


$ helm dep build 
Hang tight while we grab the latest from your chart repositories 


...Unable to get an update from the "local" chart repository (ht 
tp://127.0.0.1:8879/charts): 

Get http://127.0.0.1:8879/charts/index.yaml: dial tcp 127.0. 
0.1:8879: getsockopt: connection refused 
...Successfully got an update from the "stable" chart repository 
Update Complete. Happy Helming! * 
Saving 1 charts 
Downloading mongodb from repo https://kubernetes-charts.storage. 
googleapis.com/ 


修改 mongodb chart & £ 
将 刚才 下 载 的 charts/mongodb-0.4.17.tgz 给 解压 后 ， 修 改 其 中 的 配置 : 


e 将 persistence 下 的 enabled 设置 为 false 
e 将 image 修 改 为 我 们 的 私有 镜像 : harbor-001.jimmysong.io/library/bitnami- 
mongodb:3.4.9-r1 


执行 helm install --dry-run --debug . 确定 模板 无 误 。 


将 修改 后 的 mongodb chart 打 包 ， 在 mongodb 的 目录 下 执行 : 


helm package . 


现在 再 访问 前 面 启动 的 helm server http://localhost:8879 将 可 以 在 页 面 上 看 
到 mongodb-0.4.17 这 个 chart。 


我 们 对 官方 chart 配 置 做 了 如 下 修改 后 推送 到 了 自己 的 chart 仓 库 : 


e requirements.yaml 和 requirements.lock 文件 中 
的 repository 为 http://localhost :8879 

e 将 values.yaml 中 的 storageClass 设置 为 null 

e 将 values.yaml 中 的 Image 都 改 为 私有 镜像 

e repositroy 都 设置 为 http://localhost:8879 


注 : 因为 我 们 没有 使 用 PVC 所 以 将 所 有 的 关于 持久 化 存储 的 配置 都 设置 为 false 了 。 
部 署 MEAN 


在 mean 目录 下 执行 : 


helm install . 

NAME : orbiting-platypus 

LAST DEPLOYED: Wed Oct 25 16:21:48 2017 
NAMESPACE: default 

STATUS: DEPLOYED 


RESOURCES: 

==> vi/Secret 

NAME TYPE DATA AGE 

orbiting-platypus-mongodb Opaque 2 2s 

==> vi/ConfigMap 

NAME DATA AGE 

orbiting-platypus-mean 1 2s 

==> vi/Service 

NAME CLUSTER-IP EXTERNAL-IP PORT(S) 
AGE 

orbiting-platypus-mongodb 10.254.144.208 <none> 27017/TC 

P 2s 

orbiting-platypus-mean 10.254.165.23 <none> 80/TCP 
2S 


==> extensions/vibeta1/Deployment 


NAME DESIRED CURRENT UP-TO-DATE AVAILAB 
LE AGE 
orbiting-platypus-mean 1 1 1 0 
2S 
orbiting-platypus-mongodb 1 1 1 0 
2S 
NOTES: 


Get the URL of your Node app by running: 


export POD NAME-$(kubectl get pods --namespace default -1 "app 
-orbiting-platypus-mean" -o jsonpath="{.items[0].metadata.name}") 


echo http://127.0.0.1:8080/ 
kubectl port-forward $POD NAME 8080:80 


Bl——————————————————— 


这 样 MEAN 软 件 栈 就 部 署 到 你 的 kuberentes 集 群 里 面 了 (默认 是 在 default 
namespace 下 ) 。 


验证 检查 


为 了 验证 MEAN 是 否 安装 成 功 过 ， 可 以 使 用 kubectl get pods 查看 pod 是 否 启 动 
完成 ， 会 先 启动 mongodb 的 pod， 然 后 启动 MEAN 中 的 4 步 init。 


访问 Web UI 


在 Ingress 中 增加 如 下 配置 : 


- host: mean.jimmysong.io 
http: 
paths: 
- backend: 
serviceName: orbiting-platypus-mean 
servicePort: 80 
path: / 


然后 在 页 面 中 更 新 ingress: 


kubectl repalce -f ingress.yaml 


关于 Ingress 配 置 请 参考 : 边缘 节点 配置 


然后 在 本 地 的 /etc/hosts 文件 中 增加 一 条 配置 : 


172.20.0.119 mean. jimmysong.io 


i& : 172.20.0.119 即 边缘 节点 的 VIP。 
因为 该 页 面 需要 加 载 google 的 angularjs、 还 有 两 个 css 在 国内 无 法 访问 ， 可 以 使 用 


curl 3] zx, : 


curl mean.jimmysong.io 


将 会 返回 HTML 内 容 : 


<!doctype html» 


<!-- ASSIGN OUR ANGULAR MODULE --> 
<html ng-appz"scotchTodo"» 


<head> 
<!-- META --> 
<meta charset="utf-8"> 


1$ Jl Helm @ #2kubernetes & M 


«meta namez"viewport" content="width=device-width, initial-s 
cale=1"> 
«!-- Optimize mobile viewport --> 


<title>Node/Angular Todo App</title> 


<!-- SCROLLS --> 

<link rel="stylesheet" href="//netdna.bootstrapcdn.com/boots 
trap/3.0.0/css/bootstrap.min.css"> 

<!-- load bootstrap --> 

<link rel="stylesheet" href="//netdna.bootstrapcdn.com/font - 
awesome/4.0.3/css/font-awesome.min.css"> 


<style> 
html { 
overflow-y: scroll; 
j 
body ( 
padding-top: 50px; 
} 


#todo-list { 
margin-bottom: 30px; 
j 


#todo-form { 
margin-bottom: 50px; 
} 
</style> 
<!-- SPELLS --> 
<script src="//ajax.googleapis.com/ajax/libs/angularjs/1.2.1 
6/angular .min.js"></script> 


<!-- load angular --> 


<script src="js/controllers/main.js"></script> 


<!-- load up our controller --> 
<script src="js/services/todos.js"></script> 
<!-- load our todo service --> 
<script src="js/core.js"></script> 
<!-- load our main application --> 
</head> 


<!-- SET THE CONTROLLER --> 


<body ng-controller="mainController"> 
«div class="container"> 


<!-- HEADER AND TODO COUNT --> 
<div class="jumbotron text-center"> 
<hi>I'm a Todo-aholic <span class="label label-info"> 
{{ todos.length }}</span></h1> 
</div> 
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<!-- TODO LIST --> 
«div id-"todo-list" class="row"> 
«div class="col-sm-4 col-sm-offset-4"> 


<!-- LOOP OVER THE TODOS IN $scope.todos --> 
<div class="checkbox" ng-repeat="todo in todos"> 
<label> 
<input type="checkbox" ng-click="deleteT 
odo(todo._id)"> {{ todo.text }} 
</label> 
</div> 


«p class="text-center" ng-show="loading"> 
<span class="fa fa-spinner fa-spin fa-3x"></ 


span» 
</p> 
</div> 
</div> 
<!-- FORM TO CREATE TODOS --> 
«div id="todo-form" class="row"> 
<div class="col-sm-8 col-sm-offset-2 text-center"> 
<form> 
<div class="form-group"> 
<!-- BIND THIS VALUE TO formData.text IN 
ANGULAR --> 


<input type="text" class="form-control i 
nput-lg text-center" placeholder="I want to buy a puppy that wil 
l love me forever" ng-model="formData.text"> 

</div> 


<!-- createToDo() WILL CREATE NEW TODOS --> 
<button type="Submit" class="btn btn-primary 
btn-lg" ng-click="createTodo( )">Add</button> 
</form> 
</div> 
</div> 


<div class="text-center text-muted"> 
<p>A demo by <a href="http://scotch.io">Scotch</a>.</ 
p> 
<p>Read the «a href="http://scotch.io/tutorials/java 
script/creating-a-single-page-todo-app-with-node-and-angular"»tu 
torial</a>.</p> 
</div> 


</div> 
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«/body» 


«/html» 
ki mi >| 





访问 http://mean.jimmysong.io 可 以 看 到 如 下 界面 ， 我 在 其 中 添加 几 条 todo : 





口 Node/Angular Todo App x 


€ (ed i | mean jimmysong.io * | $9oOo«050: 





I'm a Todo-aholic F7 


C Bird goes tweet 
O Cat goes meow 
( Cow goes moo 
O What does the fox say? 


| want to buy a puppy that will love me forever 


Add 





A demo by Scotch. 


Read the tutorial. 


source https:/jimmysong.io 


AA -TODOS M #4) Web d 


注 : Todo 49 x? xx & What does the fox say? 
测试 完成 后 可 以 使 用 下 面 的 命令 将 mean chart 推 送 的 本 地 chart 仓 库 中 。 


在 mean 目 录 下 执行 : 


955 


helm package . 


再 次 刷新 http://localhost:8879 将 可 以 看 到 如 下 三 个 chart : 


e mean 
o mean-0.1.3 
e mongodb 
o mongodb-0.4.17 
e mychart 
o mychart-0.1.0 


e Deploy, Scale And Upgrade An Application On Kubernetes With Helm 

e Helm charts 

e Go template 

e Helm docs 

e How To Create Your First Helm Chart 

e Speed deployment on Kubernetes with Helm Chart — Quick yaml example 
from scratch 
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构建 私有 Chart 仓 库 


使 用 Chart 便 于 封装 和 管理 kubernetes 中 的 应 用 ， 因 此 当 企 业内 部 的 应 用 多 了 以 后 ， 
互相 依赖 、 部 署 环境 复杂 之 后 ， 原 先 的 直接 使 用 yaml| 文 件 的 管理 方式 已 经 不 再 适应 
生产 的 需要 ， 因 此 我 们 有 必要 构建 自己 的 chart 仓 库 。 本 文中 我 们 将 使 用 GitHub 
Pages 来 构建 我 们 自己 的 chart 仓库 。 


目的 


我 们 需要 构建 一 个 GitHub pages 存 储 所 有 chart 的 压缩 文件 ， 最 好 还 要 有 一 个 前 端 来 
展示 和 搜索 chart 。 


1t 4 x Chart 


Chart 是 helm 管 理 的 应 用 的 打包 格式 。 它 包括 如 下 特征 : 


e Chart 中 包括 一 系列 的 yaml 格 式 的 描述 文件 。 
e 一 个 Chart 只 用 来 部 署 单个 的 应 用 的 ， 不 应 该 过 于 复杂 ， 不 应 该 包含 多 个 依 
赖 ， 相 当 于 一 个 微服 务 。 


Chart 有 特定 的 目录 结构 ， 可 以 打包 起 来 进行 版 本 控制 。 


Chart 的 组 成 结构 


我 们 以 nginx 的 chart 为 例 ， 讲 解 chart 的 组 成 结构 。 





nginx/ 

Chart.yaml # 必须 : 一 个 包含 chart 的 名 称 、 版 本 和 启用 条 件 信 息 等 
的 YAML 文 件 

LICENSE # Ti: chart 的 许可 证 

README . md # Tib: 使 用 说 明 

requirements.yaml # 7%: 该 chart 的 依赖 配置 

values.yaml # 必须 : 该 chart 的 默认 配置 值 

charts/ ## qii: 包含 该 chart 依 赖 的 chart 

templates/ # 可 选 : kubernetes manifest 文 件 模 板 ， 用 于 生成 k 


ubernetes ya 文件 
templates/NOTES.txt # ° 
helm install 后 的 提示 信息 





| 
[EY 


该 chart 的 使 用 说 明和 提示 信息 文本 文件 ， 作 为 


Chart 的 安装 方式 
安装 chart 主 要 分 为 安装 本 地 定义 的 chart 和 远程 chart 仓 库 中 的 chart 两 种 方式 。 
安装 本 地 chart 


e 指定 本 地 chart 目 录 : helm install . 
e 指定 本 地 chart 压 缩 包 : helm install nginx-1.2.3.tgz 


安装 chart 仓 库 中 的 chart 


e 使 用 默认 的 远程 仓库 : helm install stable/nginx 
e 使 用 指定 的 仓库 : helm install localhost:8879/nginx-1.2.3.tgz 


实际 上 可 以 将 chart 打 包 后 作为 静态 文件 托管 到 web 服务 器 上 ， 例 如 GitHub pages 作 
为 chart 仓 库 也 可 以 。 


依赖 管理 
有 两 种 方式 来 管理 chart 的 依赖 。 


直接 在 本 的 chart 的 charts 目录 下 定义 
通过 在 requirements.yaml 文件 中 定义 依赖 的 chart 


在 每 个 chart 的 charts 目录 下 可 以 定义 依赖 的 子 chart。 子 chart 有 如 下 特点 : 


e 无 法 访问 父 chart 中 的 配置 
e 父 chart 可 以 履 盖 子 chart 中 的 配置 


Chart 仓 库 


Chart 仓库 (repository 是 一 个 用 来 托管 index.yaml 文件 和 打包 好 的 chart 文 件 
的 web 服 务 器 。 当 前 chart 仓 库 本 身 没 有 设置 身份 和 权限 验证 ， 查 看 此 链接 获取 该 问 
题 的 最 新 进展 。 


因为 chart 仓 库 只 是 一 个 HTTP 服 务 ， 通 过 HTTP GET 获 取 YAML 文 件 和 chart 的 压缩 
包 ， 所 以 可 以 将 这 些 文 件 存储 在 web 服 务 器 中 ， 例 如 GCS、Amazon S3、GitHub 
Pages 等 。 


关于 chart 仓 库 的 更 多 信息 请 参考 Helm chart 文 档 。 


4& M GitHub pagest @ charts 


我 们 在 上 文中 说 到 ，chart 可 以 使 用 GitHub pages 做 存储 ， 接 下 来 我 们 将 会 把 之 前 够 
够 构建 的 chart 上 传 到 GitHub pages 并 在 helm 中 新 增 一 个 repo 。 


构建 Monocular UI 


参考 Monocular UI 构建 Ul。 


克隆 项 目 到 本 地 


git clone https://github.com/kubernetes-helm/monocular.git 


依赖 环境 


e Angular 2 
e angular/cli 
e Typescript 
e Sass 

e Webpack 
e Bootstrap 


在 monoclar/scr/ui 目录 下 执行 以 下 命令 安装 依赖 : 


yarn install 

npm install -g @angular/cli 
npm install -g typescript 
npm install -g webpack 


运行 
使 


用 docker-compose 


最 简单 的 运行 方式 使 用 docker-compose : 


docker-comopse up 


该 命令 需要 用 到 如 下 镜像 : 


e bitnami/mongodb:3 
e bitnami/node:8 
e quay.io/deis/go-dev:v1.5.0 


会 有 一 个 很 长 的 build 过 程 ， 构 建 失败 。 


使 用 helm 


首先 需要 已 在 本 地 安装 了 helm， 并 在 kubernetes 集 群 中 安装 了 tiller， 见 使 用 helm 管 
理 kubernetes 应 用 。 


A 需要 安装 hginx ingress 

$ helm install stable/nginx-ingress 

$ helm repo add monocular https://kubernetes-helm.github.io/mono 
cular 

$ helm install monocular/monocular 


Monocular: Discover & launch x 


= C (Y © helmjimmysong.io *¥/9OSBROQO®@: 





Monocular Charts * Login with GitHub * About $ 


Discover & launch great Search charts... 
Kubernetes-ready apps 


Github What is Helm? Monocular is an Open Source project | v0.5.2 
Slack Documentation 
Twitter Wiki 


With @ by Bitnami and Deis 





图 片 - Helm monocular^t dn 


A nginx ingress 配 置 问题 ,官方 的 chart 中 api 与 ui 使 用 的 是 同样 的 domain name * 
我 使 用 的 是 traefik ingress > api 访问 不 到 ， 所 以 加 载 不 了 chart 。 


e Monocular UI 

e Helm Chart - GitHub 

e 简化 Kubernetes 应 用 部 署 工具 -Helm 之 应 用 部 署 

e Speed deployment on Kubernetes with Helm Chart — Quick YAML example 
from scratch 

e Using a private github repo as helm chart repo (https access) 
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持续 集成 与 发 布 


持续 集成 与 发 布 ， 简 称 CUVCD， 有 是 微服 务 构建 的 重要 环节 ， 也 是 DevOps 中 推崇 的 方 
法 论 。 如 何在 kubernetes 中 使 用 持续 构建 与 发 布 工具 ? 可 以 既 可 以 与 企业 内 部 原 有 
的 持续 构建 集成 ， 例 如 Jenkins， 也 可 以 在 kubernetes 中 部 署 一 套 新 的 持续 构建 与 发 
布 工 具 ， 例 如 Drone。 


Copyright © jimmysong.io 2017-2018 all right reserved > powered by 
GitbookUpdated at 2018-05-09 14:15:47 


使 用 Jenkins 进 行 持 续集 成 与 发 布 


我 们 基于 Jenkins 的 CHMCD 流 程 如 下 所 示 。 
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a £ e. | | User defined 
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> E. mr *  Docker 5 J : 
di ca | 3 m re i ett. Service Name 
' Ev] serviceName: my-nginx 
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AK - 基于 Jenkins 的 持续 集成 与 发 布 


流程 说 明 
应 用 构建 和 发 布 流程 说 明 。 


用 户 向 Gitlab 提 交代 码 ， 代 码 中 必须 包含 Dockerfile 

2. 将 代码 提交 到 远程 仓库 

3. 用 户 在 发 布 应 用 时 需要 堪 写 git 仓 库 地 址 和 分 支 、 服 务 类 型 、 服 务 名 称 、 资 源 数 
量 、 实 例 个 数 ， 确 定 后 触发 Jenkins 自 动 构建 

4. Jenkins 的 CI 流水 线 自动 编译 代码 并 打包 成 docker 镜 像 推 送 到 Harbor 镜 像 仓库 

5. Jenkins 的 Cl 流水 线 中 包括 了 自 定义 脚本 ， jones 已 准备 好 的 kubernetes 的 
YAML 模 板 ， 将 其 中 的 变量 替换 成 用 户 输 入 的 选 


6. 生成 应 用 的 kubernetes YAML & & X 4t 

7. 更 新 Ingress 的 配置 ， 根 据 新 部 署 的 应 用 的 名 称 ， 在 ingress 的 配置 文件 中 增加 
一 条 路 由 信息 

8. 更 新 PowerDNS， 向 其 中 插入 一 条 DNS 记 录 ，IP 地 址 是 边缘 节点 的 IP 地 址 。 关 
于 边缘 节点 ， 请 查看 边缘 节点 配置 

9. Jenkins 调 用 kubernetes 的 API， 部 署 应 用 
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使 用 Drone 进 行 持续 构建 与 发 布 


Drone 是 一 个 用 Go 语言 开发 的 基于 容器 运行 的 持续 集成 软件 。 


Ac 2 GitHub 


使 用 Drone 对 GitHub 上 的 代码 进行 持续 构建 与 发 布 ， 需 要 首先 在 GitHub 上 设置 一 个 
OAuth ， 如 下 : 


1. 在 Github 上 创建 一 个 新 的 OAtuh 应 用 


访问 此 页 面 ， 创 建新 的 OAuth 应 用 。 


C) New OAuth Application x 


c C (Y | @ GitHub, Inc. [US] | https://github.com/settings/applications/new & *1 90980 O0: 


o Pullrequests Issues Marketplace Explore A 十 ~ 网 - 


Register a new OAuth application 


Application name 
Drone 


Something users will recognize and trust 
Homepage URL 


http://localhost 


The full URL to your application homepage 


Application description 


This is displayed to all users of your application 
Authorization callback URL 


http://localhost 


Your application's callback URL. Read our OAuth documentation for more information. 


Register application Cancel 


© 2017 GitHub, Inc. Terms Privacy Security Status Help Contact GitHub API Training Shop Blog About 


EA - OAuthi AA 


w E E BP AL AA wz EAWAT > MARMA http://localhost 。 
2. 获取 OAtuh Client IDZe Client Secret 


在 注册 完成 后 就 可 以 获得 如 下 图 所 示 的 OAuth Client ID 和 Client Secret > 44 F 
来 ， 我 们 后 面 要 用 到 。 


©) OAuth Application Settings — x 


— Q Q | à GitHub, Inc. [US] | https://github.com/settings/applications/610264 Qe $080 09: 


GO Pullrequests Issues Marketplace Explore hm 十 ~ A- 


Settings Developer settings 


| OAuth Apps Drone 


GitHub Apps - 
a rootsongjc owns this application. Transfer ownership 
Personal access tokens 


You can list your application in the GitHub Marketplace so that 
other users can discover it. 


List this application in the Marketplace 


1 user 


Client ID 
0741. "mum S 


Client Secret 
bco1l^ >- mmm 





Revoke all user tokens Reset client secret 


Application logo 


Upload new logo 
o You can also drag and drop a picture from your computer. 





Ww 


Application name 


Drone 


Something users will recognize and trust 
Homepage URL 


htto://localhost 


E HA - OAuth key 


^ 


使 用 docker-compose 单 机 运行 


我 们 在 本 地 环境 ， 使 用 docker-compose， 按 照 Drone 官 方 安装 文档 安装 配置 
Drone ° 


我 们 将 代码 托管 在 Github 上 ， 需 要 Drone 可 以 持续 集成 和 发 布 Github 的 代码 ， 因 此 
需要 修改 docker-compoe.yaml 文件 中 的 GitHub 配 置 。 


version: '2' 


services: 
drone-server: 
image: drone/drone:0.8 


ports: 
- 80:8000 
- 9000 
volumes: 
- /var/lib/drone:/var/lib/drone/ 
restart: always 
environment: 
- DRONE_OPEN=true 
- DRONE_HOST=${DRONE_HOST} 
- DRONE GITHUB-true 
- DRONE_GITHUB_CLIENT=${DRONE_GITHUB_CLIENT} 
- DRONE_GITHUB_SECRET=${DRONE_GITHUB_SECRET } 
- DRONE SECRET-$(DRONE SECRET) 


drone-agent: 
image: drone/agent:0.8 


command: agent 
restart: always 
depends on: 
- drone-server 
volumes: 
- /var/run/docker.sock:/var/run/docker.sock 
environment: 
- DRONE_SERVER=drone-server : 9000 
- DRONE SECRET-$(DRONE SECRET) 


e /var/lib/drone 是 在 本 地 挂 载 的 目录 ， 请 确保 该 目录 已 存在 ， 且 可 以 被 
docker 访 问 到 ，Mac 下 可 以 在 docker 的 共享 目录 中 配置 。 

e DRONE_SECRET 可 以 是 一 个 随机 的 字符 串 ， 要 确保 drone- 
server 与 drone-client 的 DRONE_SECRET 相同 。 

e DRONE_GITHUB_CLIENT 和 DRONE GITHUB SECRET 即 在 前 面 申 请 的 OAuth 的 
Client ID 和 Client Secret 。 


尼 动 Drone 


使 用 下 面 的 命令 在 本 地 启动 drone : 


docker-compose up 


这 样 是 在 前 台 启 动 ， 加 上 -d AART AER EB o 


访问 http://localhost 可 以 看 到 登陆 画面 。 


使 用 Drone 进 行 持续 集成 与 发 布 


C) Authorize application x 


€> Q0 € â GitHub, Inc. [US] | https://github.com/login/oauth/authorize?... tr | $085.09 


ee) 


Authorize Drone 











Drone by rootsongjc 
wants to access your rootsongjc account 


Personal user data v 
Email addresses (read-only) 


Pr 


Repositories v 
Public and private 


Organizations and teams v 
Read-only access 


bs 


Organization access 

T= doczhen X Request 
{=} kBsmeetup X Request 
TalkingData X Request 
© CloudNativeworld x Grant 


Authorize rootsongjc 


Authorizing will redirect to 
http://localhost 


@ Not owned or © Created day ago åf Fewer than 10 
operated by GitHub GitHub users 


Learn more about OAuth 


AR - Drone 登 陆 界面 


授权 后 可 以 看 到 GitHub repo 设 置 。 
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使 用 Drone 进 行 持 续集 成 与 发 布 


© account | drone x 


E> cf © localhost/account 妆 | S9o0oekO0O © 


^ Account e: 





© SHOW TOKEN 


€> SYNC LIST rootsongjc/Cloud-Native-Python 
rootsongjc/Eagle 

rootsongjc 
rootsongjc/Metamorphosis 
rootsongjc/RocketMQ 
rootsongjc/alloy 
rootsongjc/alluxio 
rootsongjc/ambari 
rootsongjc/automator-workflows 
rootsongjc/awesome-cloud-native le 
rootsongjc/awesome-go 
rootsongjc/beautifulhugo 


rootsongjc/catalog-hadoop 


rootsongjc/cattle 


Successfully activated rootsongjc/awesome-cloud-native 


图 片 - Github 启 用 repo 设 置 


e 0 0 0 0 % 9 9 0 0097 $T 9 9 
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使 用 Drone 进 行 持 续集 成 与 发 布 


@ rootsongic/awesome-cloud-r- x 








€ en fo) localhost/rootsongic/awesome-cloud-native/settings * S9O0a8kQO @ : 
^ rootsongjc / awesome-cloud-native e: 
Filter... Builds Badges Settings Secrets 


rootsongjc/alloy 


Q@ - Push Hooks @ 
@ - 
rootsongjc/awesome-cloud- Pull Request Hooks € 
native 
Q as 
Mi Tag Hooks & 
Deploy Hook @ 
Trusted 9 
Gated eo 
Timeout ep 60 minutes 


图 片 - Github 单 个 repo 设 置 


e Drone Installation 
e Github - Drone 
e Drone 搭配 Kubernetes 4f 4& J& M 42 XJ A - blog.wu-boy.com 
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使 用 Drone 进 行 持续 集成 与 发 布 
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更 新 与 升级 


Kubernetes 到 目前 为 止 基本 保持 三 个 月 发 行 一 个 新 版 本 的 节奏 ， 更 新 节奏 可 以 说 非 
常 快 ， 这 一 部 分 将 主要 跟踪 kubernetes 及 其 相关 组 件 的 Pee 升级 。 
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手动 升级 kubernetes 集 群 


ee 写作 本 书 的 时 候 ， kubernetes 刚 1 发 布 1.6.0 版 本 ， 而 kubernetes 基 本 按照 

三 个 月 发 布 一 个 大 版 本 的 速度 迭代 ， 为 了 使 用 新 特性 和 只 支持 新 版 本 kubernetes 

配套 软件 ， 升 级 kubernetes er 睫 ， 在 此 我 们 使 用 替换 kubernets 的 昌 的 二 进 
制 文件 这 种 暴力 的 方式 来 升级 测试 集群 ， 若 升级 生产 集群 还 望 三 思 。 


另外 ， 自 kubernetes1.6 版 本 之 后 发 布 的 1.7 和 1.8 版 本 又 增加 了 一 些 新 特性 ， 参 考 : 


e Kubernetes1.7 更 新 日 志 
+ 


e Kubernetes1.8 € 475 & 


目前 kubernetes 的 官方 文档 上 并 没有 详细 的 手动 安装 的 集群 如 何 升 级 的 参考 资料 ， 
只 有 两 篇 关于 kubernetes 集 群 升 级 的 文档 。 


e 在 Ubuntu 上 如 何 使 用 juju 升 级 : https://kubernetes.io/docs/getting-started- 
guides/ubuntu/upgrades/ 

e 使 用 kubeadm 升 级 ; https://kubernetes.io/docs/tasks/administer- 
cluster/kubeadm-upgrade-1-7/ 


手动 升级 的 还 没有 详细 的 方案 , 大 多 是 基于 管理 工 具 部 署 和 升级 ， 比如 juju 
kubeadm、kops、kubespray 等 。 


manual upgrade/downgrade testing for Kubernetes 1.6 - google group， 在 这 个 
Google group 中 讨论 了 kubernetes 手 动 升级 的 问题 ， 并 给 出 了 参考 建议 。 


升级 步 又 


注意 : 该 升级 步骤 是 实验 性 的 ， 建 议 在 测试 集群 上 使 用 ， 无 法 保证 线 上 服务 不 
中 断 ， 实 际 升级 完成 后 无 需 对 线 上 服务 做 任何 操作 。 


大 体 上 的 升级 步骤 是 ， 先 升级 master 节 点 ， 然 后 再 一 次 升级 每 台 node 节 点 


升级 建议 


下 图 来 自 @ahmetb 的 Twitter， 这 是 他 对 于 0 宕 机 时 间 的 kubernetes 集 群 升级 建议 。 


© Zero-downtime upgrades on Kubernetes Engine (6kt) 








@ahmetb 
Your applications can drop 
Bie cganectnns od lee Eoo ie 
Seien m a aa eos to handle readiness & health probes 


` " " + 
Kubernetes wpa od of while Gavia Ahese jus para aww 


è 
; New ty Flic €^ Your A 
out a New Version Of is still wot (tod To AC 


youc app. You Can avoid this: oc while it is “shutting 
down. 










it Your ape does not exit 
30 seconds after a S\GTERM 
VS Sent, it I Killed forcefully use higher-level Controllers 
with a S\GKILL. You Can j like “De lowest" which let 
change {his duration in Pod s you configure rolling update 
confira: sb ecmindtion Grace Ror iodSeconds”. Strateg es like max Sur ae. 


e - 5 ond maxUnavatlable. 
g um m Pod Disruption Budgets 


DBS help Du configure minA Valable 
replicas Count {or G Deployme nt, so 






once your a gets A 
SIGTERM, ou should stop 
accepting New requests, 
Save uour state ond 
exit cleanly with Code <0. 


instead of Pod or ReplicaSet,, 









This hook is Called before SIGTERM 
IS Sent. lt is & good place to change 
the response to the liveness "X 


+nof the evictions are not too disrup \ 





图 片 - Kubernetes € z put ll JF 28 3£ AW 


主要 包括 以 下 建议 : 


e 应 用 使 用 高 级 对 象 定义 ， 如 支持 滚动 更 新 的 Deployment 对 象 

e 应 用 要 部 署 成 多 个 实例 

e 使 用 pod 的 preStop hook， 加 强 pod 的 生命 周期 管理 

e 使 用 就 绪 和 健康 检查 探 针 来 确保 应 用 存活 和 及 时 阻拦 应 用 流量 的 分 发 


准备 
1. 备份 kubernetes 原 先 的 二 进 制 文件 和 配置 文件 。 
2. 下 载 最 新 版 本 的 kubernetes 二 进 制 包 ， 如 1.8.5 版 本 ， 查 看 changelog， 下 载 二 


进 制 包 ， 我 们 使 用 的 是 kubernetes-server-linux-amd64.tar.gz， 分 发 到 集群 的 
Sq grub 


$+ Zt master ? 点 


停止 master 节 点 的 进程 


systemctl stop kube-apiserver 
systemctl stop kube-scheduler 
systemctl stop kube-controller-manager 
systemctl stop kube-proxy 

systemctl stop kubelet 


使 用 新 版 本 的 kubernetes 二 进 制 文件 替换 原来 老 版 本 的 文件 ， 然 后 启动 master 节 点 
上 的 进程 : 


systemctl start kube-apiserver 
systemctl start kube-scheduler 
systemctl start kube-controller-manager 


为 我 们 的 master 节 点 同时 也 作为 node 节 点 ， 所 有 还 要 执行 下 面 的 "升级 node 节 
点 “中 的 步骤 。 


Ad 
升级 node 节 点 
X swap 
# 临时 关闭 
swapoff -a 
# 永久 关闭 ， 注 释 择 Swap 分 区 即 可 


#UUID=65c9f 92d - 4828 -4d46-bf19-fb78a38d2fd1 swap 
swap defaults 0 0 


修改 kubelet 的 配置 文件 


将 kubelet 的 配置 文件 /etc/kubernetes/kublet 配置 文件 中 
的 KUBELET API SERVER-"--api-servers-http://172.20.0.113:8080" 行 注 
释 掉 。 


注意 : : kubernetes1.7 及 以 上 版 本 已 经 没有 该 配置 了 ，API server 的 地 址 写 在 
了 kubeconfig 文 件 中 。 


停止 node 节 点 上 的 kubernetes 进 程 : 


systemctl stop kubelet 
systemctl stop kube-proxy 


使 用 新 版 本 的 kubernetes 二 进 制 文件 替换 原来 老 版 本 的 文件 ， 然 后 启动 node 节 点 上 
的 进程 


systemctl start kubelet 
systemctl start kube-proxy 


启动 新 版 本 的 kube-proxy 报 错 找 不 到 conntrack 命令 ， 使 用 yum install -y 
conntrack-tools 命令 安装 后 重启 kube- rs 


到 此 升级 完成 ， 在 master 节 点 上 检查 节点 状态 : 


NAME STATUS ROLES AGE VERSION 
172.20.0.113 Ready <none> 244d v1.8.5 
172.20.0.114 Ready <none> 244d v1.8.5 
172.20.0.115 Ready <none> 244d v1.8.5 
所 有 节点 的 状态 都 正常 ， 再 检查 下 原先 的 运行 在 kubernetes 之 上 的 服务 是 否 正常 ， 


如 果 服 务 正 常 的 话说 明 这 次 升级 无 误 。 


API 版 本 变更 适 配 


对 于 不 同 版 本 的 Kubernetes， 许 多 资源 对 象 的 API 的 版 本 可 能 会 变更 ， 下 表 列 出 了 
kubernetes1.5 至 1.9 的 API 资 源 对 象 的 版 本 演进 


Dy, 


Z2 





Catalog 


Workloads 


Discovery & 
Load Balancing 


Config & 
Storage 


Metadata 


Cluster 














Kubernetes 资 源 对 象 的 版 本 演进 
16 17 

Group Version Group Version Group 
Container Core vl Core vi Core 
CronJob Batch v2alphal Batch v2alphal Batch 
DaemonSet Extensions vibetal Extensions ^ vlbetal Extensions 
Deployment Extensions vibetal Apps vibetal Apps 
Job Batch vl Batch vl Batch 
Pod Core vl Core vl Core 
ReplicaSet Extensions vibetal Extensions vlbetal Extensions 
ReplicationController Core vl Core vl Core 
StatefulSet Apps vlbetal Apps vlbetal Apps 
Endpoints Core vl Core vl Core 
Ingress Extensions vlbetal Extensions vlbetal Extensions 
Service Core vl Core vl Core 
ConfigMap Core vl Core vl Core 
Secret Core vl Core vl Core 
PersistentVolumeClaim Core vl Core vl Core 
StorageClass Storage vibetal Storage vibetal Storage 
Volume Core vl Core vl Core 
VolumeAttachment 
ControllerRevision Apps 
CustomResourceDefinition 
Event Core vl Core vl Core 
LimitRange Core vl Core vl Core 
ExternalAdmissionHookConfiguration AdmissionRegistration 
HorizontalPodAutoscaler Autoscaling vl Autoscaling v1 Autoscaling 
InitializerConfiguration AdmissionRegistration 
MutatingWebhookConfiguration 
ValidatingWebhookConfiguration 
PodTemplate Core vl Core vl Core 
PodDisruptionBudget Policy vibetal Policy vibetal Policy 
ThirdPartyResource Extensions vibetal Policy vibetal Extensions 
PriorityClass 
PodPreset Settings vlalphal Settings 
PodSecurityPolicy Extensions — vlbetal Extensions 
APIService ApiRegistration 
Binding Core vl Core vl Core 
CertificateSigningRequest Certificates vlalphal Certificates vlbetal Certificates 
ClusterRole RbacAuthorization vlalphal RBAC vlbetal RBAC 
ClusterRoleBinding RbacAuthorization vlalphal RBAC vlbetal RBAC 
ComponentStatus Core vl Core vl Core 
LocalSubjectAccessReview Authorization vlbetal Authorization v1 Authorization 
Namespace Core vl Core vl Core 
Node Core vl Core vl Core 
PersistentVolume Core vl Core vl Core 
ResourceQuota_ Core vl Core vl Core 
Role RbacAuthorization vlalphal RBAC vlbetal RBAC 
RoleBinding RbacAuthorization vlalphal RBAC vlbetal RBAC 
SelfSubjectAccessReview Authorization vlbetal Authorization vl Authorization 
SelfSubjectRulesReview 
ServiceAccount Core vl Core vl Core 
SubjectAccessReview Authorization vibetal Authorization vl Authorization 
TokenReview Authentication vlbetal Authorization v1 Authorization 
NetworkPolicy Extensions vibetal Extensions vlbetal Networking 


图 片 - Kuberentes APIs $& 85 nk A 


18 
Version Group 
vi Core 
v2alphal Batch 
vibetal Apps 
vlbetal Apps 
vi Batch 
vl Core 
vlbetal Apps 
vl Core 
vibetal Apps. 
vl Core 
vibetal Extensions 
vl Core 
vl Core 
vl Core 
vl Core 
vl Storage 
vi Core 
vibetal Apps 
ApiExtensions 
vl Core 
vl Core 
vlalphal AdmissionRegistration 
vl Autoscaling 
vlalphal AdmissionRegistration 
vl Core 
vibetal Policy 
vibetal 
Scheduling 
vlalphal Settings 
vlbetal Extensions 
vlbetal  ApiRegistration 
vl Core 
vibetal Certificates 
vibetal RBAC 
vibetal RBAC 
vl Core 
vl Authorization 
vl Core 
vl Core 
vl Core 
vl Core 
vlbetal RBAC 
vlbetal RBAC 
vl Authorization 
Authorization 
vl Core 
vl Authorization 
vl Authorization 
vl Networking 


B 


85 


xt 
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Version Group 
vl Core 
vibetal Batch 
vibeta2 Apps 
vibeta2 Apps 
vl Batch 
vl Core 
vibeta2 Apps 
vl Core 
vlbeta2 Apps 
vl Core 
vibetal Extensions 
vl Core 
vl Core 
vl Core 
vl Core 
vl Storage 
vl Core 
Storage 
vibeta2 Apps 
vlbetal ApiExtensions 
vl Core 
vl Core 
vlalphal 
vl Autoscaling 
vlalphal AdmissionRegistration 
AdmissionRegistration 
AdmissionRegistration 
vi Core 
vlbetal Policy 
vlalphal Scheduling 
vlalphal Settings 
vlbetal Extensions 
vibetal ApiRegistration 
vl Core 
vlbetal Certificates 
vl RBAC 
vl RBAC 
vl Core 
vl Authorization 
vl Core 
vl Core 
vl Core 
vl Core 
vl RBAC 
vl RBAC 
vl Authorization 
vl Authorization 
vl Core 
vl Authorization 
vl Authorization 
vl Networking 


vibetal 


vibetal 


vlalphal 


vlbetal 


vlalphal 
vlbetal 
vlbetal 
vl 


vlbetal 


vlalphal 
vlalphal 
vibetal 
vibetal 
vi 
vibetal 
vl 

vi 

vi 


vl 


当 我 们 升级 过 后 ， 可 能 出 现 资 源 对 象 的 API 变 更 后 ， 原 先 的 YAML 文 件 无 法 使 用 的 情 
况 ， 因 此 需要 对 新 版 本 的 Kubernetes 进 行 适 配 。 对 应 的 API 版 本 转换 工 
E : https://github.com/fleeto/kube-version-converter > "T 43$ Kuberntes API 对 象 
转换 到 指定 版 本 。 
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手动 升级 Kubernetes 集 群 


Cluster Upgrade #2524 

Upgrading self-hosted Kubernetes 

Upgrading Kubernetes - kops 

Upgrading kubeadm clusters from 1.6 to 1.7 

How to Upgrade a Kubernetes Cluster With No Downtime 

manual upgrade/downgrade testing for Kubernetes 1.6 - google group 
Notes/Instructions for Manual Upgrade Testing1.5 -> 1.6 

Upgrading Kubernetes in Kubespray 
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4+ 4 Dashboard 


我 们 在 kubernetes1.6 的 时 候 同 时 安装 了 dashboard 插 件 ， 该 插件 也 是 基于 
kubernetes1.6 版 本 开发 的 。 如 今 kubernetes1.8 版 本 业已 发 布 ， 如 何 升 级 dashboard 
以 获取 新 版 中 功能 呢 ? 


Dashboard 的 升级 比较 简单 ， 因 为 它 仅 仅 是 一 个 前 端 应 用 ， 用 来 展现 集群 信息 和 与 
后 端 API 交 互 ， 理 论 上 只 需要 更 新 原先 dashboard 的 yaml 配 置 文件 中 的 镜像 就 可 以 
了 ， 但 是 为 了 使 用 dashboard1.7 版 本 中 的 用 户 登 陆 功能 ， 还 需要 做 一 些 额外 的 操 

作 。 


dashboard 的 更 新 日 志 请 见 release note， 当 前 的 最 新 版 本 为 v1.7.1， 下 面 将 介绍 将 
dashboard 从 v1.6.3 升 级 到 v1.7.1 并 开启 用 户 登 陆 认证 的 详细 步骤 。 


升级 步骤 
删除 原来 的 版 本 


首先 删除 原来 的 dashboard 资 源 : 


kubectl delete -f dashboard/ 
将 dashboard 目录 下 的 所 有 yaml 文 件 中 的 资源 全 部 删除 ， 包 括 Deployment、 
service 和 角色 绑 定 等 。 
部 署 新 版 本 
我 们 使 用 官方 的 配置 文件 来 安装 ， 首 先 下 载 官方 配置 


wget https://raw.githubusercontent.com/kubernetes/dashboard/mast 
er/src/deploy/recommended/kubernetes - dashboard. yaml 


修改 其 中 的 两 个 镜像 地 址 为 我 们 的 私有 地 址 。 


e gcr.io/google containers/kubernetes-dashboard-init-amd64:v 1.0.1 
e gcr.io/google_containers/kubernetes-dashboard-amd64:v1.7.1 


这 个 两 个 镜像 可 以 同时 从 时 速 云 上 获取 : 


e index.tenxcloud.com/jimmy/kubernetes-dashboard-amd64:v1.7.1 
e index.tenxcloud.com/jimmy/kubernetes-dashboard-init-amd64:v1.0.1 


将 service type 设 置 为 NodePort ， 修 改 后 的 yaml 文 件 见 kubernetes- 
dashboard.yaml， 然 后 就 可 以 部 署 新 版 本 的 dashboard 了 。 


kubectl create -f kubernetes-dashboard.yaml 
获取 dashboard 的 外 网 访问 端口 : 


kubectl -n kube-system get svc kubernetes-dashboard 


NAME CLUSTER-IP EXTERNAL - IP PORT(S) 
AGE 

kubernetes-dashboard 10.254.177.181 «nodes» 443:32324/ 

TCP 49m 


访问 集群 中 的 任何 一 个 节点 ， 即 可 打开 dashboard 登 陆 页 面 ， 如 
https://172.20.0.113:32324/ (请 使 用 https 访 问 ) ， 支 持 使 
用 kubeconfig 和 token 两 种 的 认证 方式 : 


@ Sign in - Kubernetes Dashbos x 


一 Q (Y | A Not Secure | https://172.20.0.113:32324/#!/login tO : 


Kubernetes Dashboard 


Authentication method: 
(8) Kubeconfig 
O Token 


Kubeconfig YAML file * 


brand.kubeconfig 


SIGN IN SKIP 


Ft 2& dashboard 


选择 本 地 的 kubeconfig 文件 以 登陆 集群 ， kubeconfig 文件 中 包括 登陆 的 用 户 
名 、 证 书 和 token 信 息 。 


登陆 之 后 首先 看 到 的 界面 是 这 样 的 : 


© Overview - Kubernetes Dasht x 


€ Q (Y | A Not Secure | https://172.20.0.113:32324/tt! overview? namespace - default 六 OO : 


kubernetes Q Search +0 | O 


= Overview 


集群 
命名 空间 
节点 
持久 化 存储 卷 
角色 
存储 类 











ores 
无 内 容 显示 
default — 现在 就 部 署 容器 应 用 、 查 看 其 它 命名 宝 间 ， 或 浏览 控制 面板 概览 世 来 了 解 更 多 


命名 空间 





Overview 


工作 负载 
守护 进程 集 
am 


图 片 - 首页 
这 是 因为 该 用 户 没 有 对 default 命名 空间 的 访问 权限 。 


修改 URL 地 址 中 的 namespace 字段 为 该 用 户 有 权限 访问 的 命名 空间 如 
brand : https://172.20.0.113:32324/#!/overview?namespace=brand : 
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© Overview - Kubernetes Dash: x 


€ Q (Y | A Not Secure | https://172.20.0.113:32324/#!/overview?namespace=brand zo: 


kubernetes Q Search +a | @ 








集群 
CPU usage Memory usage @ 
命名 空间 
节点 0.450 10.9 Gi 
0.400 9.69 Gi 
持久 化 存储 卷 -" i 
& 0.300 iP- 7.26 Gi 
角色 z2 0200 gp 484 Gi 
o £ r 
存储 类 0.100 2.42 Gi 
NN 18:42 15:46 15:50 15:53 15:56 18:42 15:46 15:50 15:53 15:56 
paa 时 间 时 间 
brand © 
Overview Resource Status 
工作 负载 
守护 进程 集 podá 
部 署 
E Running 15 
任务 
容器 组 — Pending 0 
副本 集 B Failed 0 
副本 控制 器 
有 状态 副本 集 
服务 发 现 与 负载 均衡 
访问 权 容器 组 as 
服务 
名 称 人 节点 状态 > 已 重启 + Z 存 (FR 
配置 与 存储 名 条 节 状 重 已 创建 CPU ( 核 ) 内 存 ( 字 节 ) 
配置 集 @ mysql3306-2553 172.20.0.113 — Running 0 21 分 钟 E ron = 
持久 化 存储 卷 索 取 
@ kafka-2 172.20.0.113 Running 0 2 小 时 1 = 
保密 字典 0.106 473.668 Mi 
图 片 - 用 户 空间 
re DEO 
设置 界面 的 语言 


我 们 看 到 现在 dashboard 的 页 面 都 已 经 被 汉化 了 ， 当 前 支持 英文 、 中 文 简体 、 中 文 
繁体 、 日 语 ， 根 据 浏览 器 的 语言 自动 切换 的 。 如 果 想 要 强制 设置 dashboard 中 显示 
的 语言 ， 需 要 在 dahsboard 的 Deployment yaml 配置 中 增加 如 下 配置 : 


env: 
- name: ACCEPT_LANGUAGE 
value: english 


XT i18n 的 设计 文档 请 参 
考 : https://github.com/kubernetes/dashboard/blob/master/docs/design/i18n.md 
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更 简单 的 方式 是 ， 如 果 您 使 用 的 Chrome 浏 览 器 ， 则 在 浏览 器 中 "n 配置 中 设置 语 
的 顺序 后 刷新 网 页 ，dashboard 将 以 您 在 Chrome 中 配置 的 首选 语言 显示 。 


身份 认证 

登陆 dashboard 的 时 候 支持 kubeconfig 和 token 两 种 认证 方式 ，kubeconfig 中 也 
依赖 token 字段 ， 所 以 生成 token 这 一 步 是 必 不 可 少 的 。 

下 文 分 两 块 来 讲解 两 种 登陆 认证 方式 : 


e A brand 命名 空间 下 的 brand pes | 建 kubeconfig 文件 
e 为 集群 的 管理 员 (拥有 所 有 命名 空间 的 amdin 权限 ) 创建 token 


使 用 kubeconfig 


登陆 dashboard 的 时 候 可 以 指定 kubeconfig 文件 来 认证 用 户 权 限 ， 如 何 生 成 登陆 
dashboard 时 指定 的 kubeconfig 文件 请 参考 创建 用 户 认 证 授权 的 kubeconfig 文 
件 。 


注意 我 们 生成 的 kubeconfig 文件 中 没有 token 字段 ， 需 要 手动 添加 该 字段 。 


比如 我 们 为 brand namespace 下 的 brand 用 户 生 成 了 名 为 brand.kubeconfig 
的 kubeconfig 文件 ， 还 要 再 该 文件 中 追加 一 行 token 的 配置 (如 何 生成 token 
将 在 下 文 介绍 ) ， 如 下 所 示 : 


l brand.kubeconfig x 





1l apiVersion: v1 

2 clusters: 

3 - cluster: 

4 certificate-authority-data: LSOtLS1CRUdJTiBDRVJUSUZJQOFURSOtLSOtCK1JSURtakN 
5 server: https://172.20.0.113:6443 
6 name: kubernetes 

7 contexts: 

8 — context: 

9 cluster: kubernetes 
10 namespace: brand 
T1 user: brand 
12 name: kubernetes 


13 current-context: "kubernetes" 
14 kind: Config 

15 preferences: {} 

16 users: 


17 - name: brand 

18 usen: 

19 client-certificate-data: LSO0tLS1CRUdJTiBDRVJUSUZJQOFURSOtLSOtCK1JSUQwakNDQX 
20 client-key-data: LSOtLS1CRUdJTiBSUOEgUFJJVKkFURSBLRVKtLSOtLQpNSULTFb3dJQkFBSO 
21 token: a09bb459d67d876cf1829b4047394a5a 


图 片 - kubeconfig X4 


这 样 就 可 以 使 用 brand.kubeconfig 文件 来 登陆 dashboard 了 ， 而 且 只 能 访问 和 操 
YE brand 命名 空间 下 的 对 象 。 


生成 集群 管理 员 的 token 


以 下 是 为 集群 最 高 权限 的 管理 员 (可 以 任意 操作 所 有 namespace 中 的 所 有 资源 ) 生 
成 token 的 步骤 详解 。 


注意 : 登陆 dashboard 的 时 候 token 值 是 必须 的 ， 而 kubeconfig 文 件 是 kubectl 命 
令 所 必须 的 ，kubectl 命 令 使 用 的 kubeconfig 文 件 中 可 以 不 包含 token 信 息 。 


需要 创建 一 个 admin 用 户 并 授予 admin 角 色 绑 定 ， 使 用 下 面 的 yaml 文 件 创 建 admin 用 
户 并 赋予 他 管理 员 权 限 ， 然 后 可 以 通过 token 登 陆 dashbaord， 该 文件 见 admin- 
role.yaml。 这 种 认证 方式 本 质 上 是 通过 Service Account 的 身份 认证 加 上 Bearer 
token 请 求 API server 的 方式 实现 ， 参 考 Kubernetes 中 的 认证 。 


kind: ClusterRoleBinding 
apiVersion: rbac.authorization.k8s.io/vibeta1 
metadata: 
name: admin 
annotations: 
rbac.authorization.kubernetes.io/autoupdate: "true" 
roleRef : 
kind: ClusterRole 
name: cluster-admin 
apiGroup: rbac.authorization.k8s.io 
subjects: 
- kind: ServiceAccount 
name: admin 
namespace: kube-system 
apiVersion: v1 
kind: ServiceAccount 
metadata: 
name: admin 
namespace: kube-system 
labels: 
kubernetes.io/cluster-service: "true" 
addonmanager.kubernetes.io/mode: Reconcile 


然后 执行 下 面 的 命令 创建 serviceaccount fe A ERZ: APH sx qa] 83 He A 
PREG REM yam 中 的 name 和 namespace 字段 即 可 : 


kubectl create -f admin-role.yaml 


创建 完成 后 获取 secret 和 token 的 值 。 


运行 下 面 的 命令 直接 获取 admin 用 户 的 token : 


kubectl -n kube-system describe secret "kubectl -n kube-system g 


et secret|grep admin-token|cut -d " " -f1°|grep "token:"|tr -s " 
"|cut -d " " -f2 
手动 获取 


也 可 以 执行 下 面 的 步骤 来 获取 token 值 : 


A 获取 admin-token 的 sSecret 名 字 
$ kubectl -n kube-system get secret|grep admin-token 


admin-token-nwphb kubernetes.io/service 
-account -token 3 6m 

# RRtoken ta 

$ kubectl -n kube-system describe secret admin-token-nwphb 

Name: admin-token-nwphb 

Namespace: kube-system 

Labels: <none> 

Annotations: kubernetes.io/service-account.name-admin 


kubernetes.io/service-account.uid-f37bd0O44-bfb3-11e7-87c 
0o -fAe9d49f8edO 


Type: kubernetes.io/service-account-token 
Data 

namespace: 11 bytes 

token: 非常 长 的 字符 串 

ca.crt: 1310 bytes 


在 dashboard 登录 页 面 上 有 两 种 登录 方式 ， kubeconfig 文件 和 token (4 
WE) ， 使 用 token 登录 可 以 直接 使 用 上 面 输出 中 的 那个 非常 长 的 字符 串 作 为 token 
登录 ， 即 可 以 拥有 管理 员 权 限 操作 整个 kubernetes 集 群 中 的 对 象 。 对 于 

kubeconfig 文件 登录 方式 ， 不 能 直接 使 用 之 前 给 kubectl 生成 的 kubeconfig 
文件 ( ~/.kube/config ) 需要 给 它 加 一 个 token 字段 ， 您 可 以 将 这 串 token 加 到 
admin 用 户 的 kubeconfig 文件 中 ， 继 续 使 用 kubeconfig 登录 ， 具 体 加 的 位 置 
可 以 参考 bootstrap-kubeconfig 文件 ， 两 种 认证 方式 任 您 选择 。 


注意 : 通过 kubectl get secret xxx 输出 中 的 token 值 需要 进行 base64 MH 
码 ， 在 线 解码 工具 base64decode，Linux 和 Mac 有 自 带 的 base64 命令 也 可 以 
直接 使 用 ， 输 入 base64 是 进行 编码 ，Linux 中 base64 -d 表示 解码 ，Mac T 
使 用 base64 -D ; 通过 kubectl describe secret xxx 输出 中 的 token 不 需 
要 base64 解码 。 


也 可 以 使 用 jsonpath 的 方式 直接 获取 token 的 值 ， 如 : 


kubectl -n kube-system get secret admin-token-nwphb -o jsonpath={ 
.data.token}|base64 -d 


S22 全 


注意 我 们 使 用 了 base64 对 其 重新 解码 ， 因 为 secret 都 是 经 过 base64 编码 的 ， 如 
果 直 接 使 用 kubectl 中 查看 到 的 token 值 会 认证 失败 ， 详 见 secret 配置 。 关 于 
JSONPath 的 使 用 请 参考 JSONPath 手册 。 


注意 : 关于 如 何 给 其 它 namespace 的 管理 员 生 成 token 请 参考 使 用 kubeconfig 或 
token 进 行 用 户 身份 认证 。 


参考 


e Dashboard log in mechanism #2093 

e Accessing Dashboard 1.7.X and above 

e Kubernetes dashboard UX for Role-Based Access Control 
e How to sign in kubernetes dashboard? - StackOverflow 

e JSONPath 手册 

e Kubernetes 中 的 认证 
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Kubernetes 和 云 原生 应 用 在 各 个 领域 中 的 实践 。 
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WIR FRA 


Kubernetes 设计 之 初 就 是 按照 Cloud Native 的 理念 设计 的 ，Cloud Native 中 有 个 
重要 概念 就 是 微服 务 的 架构 设计 ， 当 将 单 体 应 用 拆 分 微服 务 后 ， 随 着 服务 数量 的 增 
多 ， 如 何 微服 务 进行 管理 以 保证 服务 的 SLA 呢 ?为 了 从 架构 层面 上 解决 这 个 问题 ， 
ARAL RA) OIE TE > HER AHIR SG RL > M AE > PA AIRF Service 
mesh 应 运 而 生 。 


微服 务 


下 图 是 Bilgin lbryam 给 出 的 微服 务 中 应 该 关心 的 主题 ， 图片 来 自 RedHat 
Developers ° 
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图 片 - 微服 务 关注 的 部 分 


当前 最 成 熟 最 完整 的 微服 务 框架 可 以 说 非 Spring 英 属 ， 而 Spring 又 仅 限 于 Java 语 言 


开发 ， 其 架构 本 身 又 跟 Kubernetes 存 在 很 多 重合 的 部 分 ， 如 何 探索 将 Kubernetes 作 
为 微服 务 架 构 平 台 就 成 为 一 个 热点 话题 。 
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微服 务 中 的 服务 发 现 


在 单 体 架 构 时 ， 因 为 服务 不 会 经 常 和 动态 迁移 ， 所 有 服务 地 址 可 以 直接 在 配置 文件 
中 配置 ， 所 以 也 不 会 有 服务 发 现 的 问题 。 但 是 对 于 微服 务 来 说 ， 应 用 的 拆 分 ， 服 务 
之 间 的 解 碍 ， 和 服务 动态 扩展 带 来 的 服务 迁移 ， 服 务 发 现 就 成 了 微服 务 中 的 一 个 关 
键 问 题 。 


服务 发 现 分 为 客户 端 服务 发 现 和 服务 端 服 务 发 现 两 种 ， 架 构 如 下 图 所 示 。 





Service Discovery in Microservices 


Client-side Service Discovery Server-side Service Discovery 







Consume the service 


Request to consume the service 











Ribbon Request for service address ——— Infrastructure provided 
Router/Load Balancer Kubernetes/SkyDNS 
Ingress LB 

Eureka Traefik 

PowerDNS 


Register 


Forward 


© Jimmy Song https://github.com/rootsongjc/kubernetes-handbook 














图 片 - 微服 务 中 的 服务 发 现 


这 两 种 架构 都 各 有 利 藉 ， 我 们 拿 客 户 端 服务 发 现 软 件 Eureka 和 服务 端 服务 发 现 架 构 
Kubernetes/SkyDNS+Ingress LB+Traefik+PowerDNS 为 例 说 明 。 


& Pros Cons 
: 7 五 = h? RS 
使 用 简单 ， 适 用 于 java 语 言 开发 JUS eA TY 
s n 9 条 这 Z E sg ge Da dh 
Eureka 81 H 比 服务 端 服务 发 现 少 UR $e ARP ae FoF LB 
一 次 网 络 跳 转 辑 


Consumer 无 需 关注 服务 发 现 具 需要 基础 设施 支撑 ， 多 了 一 
Kubernetes 体 细节 ， 只 需 知道 服务 的 DNS 次 网 络 跳 转 ， 可 能 有 性 能 损 
域名 即 可 ， 支 持 异 构 语 言 开 发 失 


Eureka 也 不 是 单独 使 用 的 ， 一 般 会 配合 ribbon 一 起 使 用 ，ribbon 作为 路 由 和 负载 
均衡 o 


Ribbon 提 供 一 组 丰富 的 功能 集 : 


e 多 种 内 建 的 负载 均衡 规则 : 
o Round-robin 轮 询 负载 均衡 
o 平均 加 权 响 应 时 间 负 载 均衡 
o 随机 负载 均衡 
o 可 用 性 过 滤 负 载 均衡 【避免 跳闸 线路 和 高 并 发 链接 数 ) 
o 自 定 义 负 载 均衡 插件 系统 
e 与 服务 发 现 解决 方案 的 可 拔 插 集成 (包括 Eurekal) 
e 云 原 生 智能 ， 例 如 可 用 区 亲 和 性 和 不 健康 区 规避 
e 内 建 的 故障 恢复 能 力 


参考 


。 谈 服务 发 现 的 背景 、 架 构 以 及 落地 方案 
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使 用 Java 构 建 微 服务 并 发 布 到 Kubernetes 和 平台 


使 用 Java 构 建 微服 务 并 发 布 到 Kubernetes 和 十 
入 


ua 
Java 作 为 多 年 的 编程 语言 届 的 No.1 (使 用 人 数 最 多 ， 最 流行 ) ， 使 用 它 来 构建 微服 


务 的 人 也 不 计 其 数 ，Java 的 微服 务 框 架 Spring 中 的 Spring Boot 和 Spring Cloud 已 成 
为 当前 最 流行 的 微服 务 框架 。 


下 面 是 Sping 技 术 栈 所 包含 的 技术 框架 图 。 


‘ee 
spring 
= CC 








图 片 SpringdX RR 


当然 如 果 在 Kubernetes 中 运行 Java 语 言 构 建 的 微服 务 应 用 ， 我 们 不 会 使 用 上 图 中 所 
有 的 技术 ， 本 节 将 主要 讲解 如 何 使 用 Spring Boot 构 建 微服 务 应 用 。 


下 图 是 Spring Boot 的 一 些 知识 点 。 





spring-boot-starter 
spring-boot-starter-batch 
spring-boot-starter-data-jpa Tool Maven 
spring-boot-starter-data-mongodb ESL 
spring-boot-starter-data-rest AOP(Aspect Oriented Programming 


spring-boot-starter-web Dependency Injection 


@SpringBootApplication loC(Inversion of Control) 


@Configuration Load class 


@Component Spring Boot Life cycle management 


@Reposito functions Connect servlet and web app 
@Service Multi-threads support 
@Controller JSP support 
@AutoWired 
@EnableAutoConfiguration 
@ComponentScan 


META-INFO 
BOOT-INFO v1.0 https:/jimmysong.io 


图 片 - Spring Boot 的 知识 点 


Spring Boot 是 Spring 框 架 的 一 部 分 ， 关 于 Spring 的 核心 技术 请 参考 Spring core 
technologies - spring.io ° 
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Spring Boot 快 速 开 始 指南 


Spring Boot 已 成 为 当今 最 流行 的 微服 务 开发 框架 ， 本 文 是 如 何 使 用 Spring Boot 快 
速 开 始 Web 微 服务 开发 的 指南 ， 我 们 将 使 创建 一 个 可 运行 的 包含 内 奉 Web 容 器 (X 
认 使 用 的 是 Tomcat) 的 可 运行 Jar 包 


Spring Boot 家 在 简化 创建 产品 级 的 Spring 应 用 和 服务 ， 简 化 了 配置 文件 ， 使 用 肉 入 
式 Web 服 务 器 ， 含 有 诸多 开 箱 即 用 微服 务 功 能 ， 可 以 和 spring cloud 联 合 部 署 。 


传统 的 Spring 应 用 程序 需要 配置 ME 运行 ， hese Boot A $ 
极 少 的 配置 ， 就 可 以 快速 获得 一 个 正常 运行 的 Spring 应 用 程序 ， 而 这 些 配置 使 用 的 
都 是 注解 的 形式 ， 不 需要 再 配置 XML © 


与 Go 语言 的 应 用 不 同 ， 我 们 知道 所 有 的 Java Web 应 用 都 必须 放 在 servlet 容 器 (不 
是 像 docker 容 器 的 那 种 容器 ) ， 如 Tomcat、Jetty 等 。Servlet 容 器 被 定位 为 托管 web 
应 用 程序 的 高 可 用 组 件 。 £7 Servlet) d 3 4-4 Serviette | runoob.com ° 


Spring 的 基本 原理 


Spring 是 一 套 Java 开 发 框架 ， 框 架 的 作用 就 是 为 了 减少 代码 的 宛 余 和 模块 之 间 的 偶 
尔 ， 使 代码 逻辑 更 加 清晰 ， 主 要 是 用 了 AOP (Aspect Oriented Programming， 面 
向 切面 编程 ) FeloC (Inversion of Control > HRH) 容器 的 思想 ， 其 中 AOP 是 利 
用 了 Java 的 反射 机 制 实现 的 。 为 了 便于 理解 AOP 可 以 参考 一 个 简单 的 Spring 的 AOP 
例子 。 


准备 环境 
在 开始 Spring Boot 开 发 之 前 ， 需 要 先 确 认 您 的 电脑 上 已 经 有 以 下 环境 : 


e JDK8 
e Maven3.0+ 
e Intellij IDEA 


JDK 最 好 使 用 JDK8 版 本 ，Maven 和 IDEA 的 安装 都 十 分 简单 ，Maven 的 仓库 配置 有 
必要 说 一 下 。 


fe a. Maven 


在 安装 好 Maven 之 后 ， 默 认 的 ~/.m2 目录 下 是 没有 maven 仓 库 配 置 文 
件 settings.xml 的 ， 默 认 使 用 的 是 官方 的 仓库 ， 访 问 速度 会 非常 慢 ， 我 们 需要 
配置 下 国内 的 仓库 。 


创建 -/.m2/settings.xml 文件 ， 文 件 内容 如 下 : 


<?xml version="1.0"?> 
<settings> 
<mirrors> 
<mirror> 
<id>alimaven</id> 
<name>aliyun maven</name> 
<url>http://maven.aliyun.com/nexus/content/groups/pu 
blic/«/url» 
<mirrorof>central</mirrorof> 
</mirror> 
</mirrors> 
<profiles> 
«profile» 
<id>nexus</id> 
<repositories> 
<repository> 
<id>nexus</id> 
<name>local private nexus</name> 
<url>http://maven.oschina.net/content/groups/pub 
lic/«/url» 
«releases» 
<enabled>true</enabled> 
</releases> 
<snapshots> 
<enabled>false</enabled> 
</snapshots> 
</repository> 
</repositories> 


<pluginRepositories> 
<pluginRepository> 
<id>nexus</id> 
<name>local private nexus</name> 
<url>http://maven.oschina.net/content/groups/public/ 
</url> 
<releases> 
<enabled>true</enabled> 
</releases> 
<snapshots> 
<enabled>false</enabled> 
</snapshots> 
</pluginRepository> 
</pluginRepositories> 
</profile></profiles> 
</settings> 


其 中 使 用 的 是 阿里 云 的 mirror， 国 内 的 下 载 速度 非常 快 。 


创建 第 一 个 Spring Boot M 


我 们 可 以 使 用 以 下 两 种 方式 创建 Spring Boot 应 用 : 

e Springboot 

e maven 
1& F|springboot? + ¢] £ Spring Boot M 
首先 需要 安装 springboot 命令 行 工 具 。 


brew tap pivotal/tap 
brew install springboot 


使 用 下 面 的 命令 创建 应 用 。 


spring init --build maven --groupId com.example --version 0.0.1- 
SNAPSHOT --java-version 1.8 --dependencies web --name myproject 
myproject 


e --build 使 用 maven 编 译 或 者 是 gradle 
e --groupId 和 --version 与 maven 的 pom.xml 中 的 设置 对 应 
e --dependencies 可 以 指定 多 个 ， 如 web ^ jpa ^ security 等 starter 


执行 上 述 命令 后 ， 将 创建 如 下 的 目录 结构 : 


L— myproject 


L— mvnw 


mvnw.cmd 


I— 
I— pom.xml 
L 


| L— example 

| L— myproject 

| L— MyprojectApplication. java 
L— resources 

| 一 application.properties 

I— static 

L— templates 

L— java 

L— com 


L— example 
L— myproject 
L— MyprojectApplicationTests.java 


15 directories, 6 files 


运行 默认 的 示例 应 用 。 


mvn spring-boot:run 
第 一 次 运行 需要 下 载 依赖 包 所 以 会 比较 耗费 时 间 ， 以 后 每 次 编译 运行 速度 就 会 很 


在 浏览 器 中 访问 将 看 到 如 下 输出 : 


Whitelabel Error Page 
This application has no explicit mapping for /error, so you are 


seeing this as a fallback. 
Mon Mar 12 16:26:42 CST 2018 


There was an unexpected error (type=Not Found, status=404). 
No message available 


1& f] Mavené! Spring Boot 7] 


1& A Maven] 3 Spring Boot 应 用 需要 执行 以 下 步骤 : 


Spring Boot 28 EF 36 4a 


1. 创建 Maven 工 程 所 需 的 pom.xml 文件 
2. 生成 Maven 工 程 
3. 编译 打包 发 布 


创建 pom.xml 


为 Maven 项 目 构建 创建 pom.xml 文件 ， 内 容 如 下 : 


<?xml version="1.0" encoding="UTF-8"?> 


«project xmlns="http://maven.apache.org/POM/4.0.0" xsi="ht 


tp://www.w3.org/2001/XMLSchema-instance" 


schemaLocation="http://maven.apache.org/POM/4.0.0 http:/ 


/maven.apache.org/xsd/maven-4.0.0.xsd"> 
<modelVersion>4.0.0</modelVersion> 


«groupId»com.example«c/groupId» 
<artifactId>myproject</artifactId> 
<version>0.0.1-SNAPSHOT</version> 


<parent> 
«groupId»org.springframework.boot«/groupId» 
<artifactId>spring-boot-starter-parent</artifactId> 
<version>1.4.1.BUILD-SNAPSHOT</version> 

</parent> 


<repositories> 
<repository> 
<id>spring-snapshots</id> 
<url>http://repo.spring.io/snapshot</url> 
<snapshots><enabled>true</enabled></snapshots> 
</repository> 
<repository> 
<id>spring-milestones</id> 
<url>http://repo.spring.io/milestone</url> 
</repository> 
</repositories> 
<pluginRepositories> 
<pluginRepository> 
<id>spring-snapshots</id> 
<url>http://repo.spring.io/snapshot</url> 
</pluginRepository> 
<pluginRepository> 
<id>spring-milestones</id> 
<url>http://repo.spring.io/milestone</url> 
</pluginRepository> 
</pluginRepositories> 
<!-- 添加 classpath 依 赖 --> 
<dependencies> 
<dependency> 
<groupId>org.springframework.boot</groupId> 
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<artifactId>spring-boot-starter-web</artifactId> 
</dependency> 
<!-- 开发 者 工具 ， 当 classpath 下 有 文件 更 新 自动 触发 应 用 重启 --> 
<dependency> 
<groupId>org.springframework.boot</groupId> 
<artifactId>spring-boot-devtools</artifactId> 
<optional>true</optional> 
</dependency> 
</dependencies> 
«!-- maven 编 译 插件 ， 用 于 创建 可 执行 Tar 包 --> 
<build> 
<plugins> 
<plugin> 
«groupId»org.springframework.boot«/groupId» 
<artifactId>spring-boot-maven-plugin</artifactId> 


</plugin> 
</plugins> 


</build> 
</project> 


[i uae E E | 


现在 执行 mvn dependency:tree 可 以 看 到 项 目 中 的 依赖 关系 。 
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com.example:myproject:jar:0.0.1-SNAPSHOT 
\- org.springframework.boot:spring-boot-starter-web:jar:1.4.1.BU 
ILD-SNAPSHOT:compile 

*- org.springframework.boot:spring-boot-starter:jar:1.4.1.BUI 
LD-SNAPSHOT: compile 

| +- org.springframework.boot:spring-boot:jar:1.4.1.BUILD-SN 
APSHOT: compile 

| +- org.springframework.boot:spring-boot-autoconfigure:jar: 
1.4.1.BUILD-SNAPSHOT: compile 

| +- org.springframework.boot:spring-boot-starter-logging:ja 
r:1.4.1.BUILD-SNAPSHOT:compile 

| | +- ch.qos.logback:logback-classic:jar:1.1.7:compile 

| | | +- ch.qos.logback:logback-core:jar:1.1.7:compile 

| | | \- org.slf4j:slf4j-api:jar:1.7.21:compile 

| | +- org.slf4j:jcl-over-slf4j:jar:1.7.21:compile 

| | +- org.slf4j:jul-to-slf4j:jar:1.7.21:compile 

| | W org.slf4j:log4j-over-slf4j:jar:1.7.21:compile 

| +- org.springframework:spring-core:jar:4.3.3.RELEASE: compi 
le 

| \- org.yaml:snakeyaml:jar:1.17:runtime 

*- org.springframework.boot:spring-boot-starter-tomcat:jar:1. 
4.1.BUILD-SNAPSHOT : compile 

| +- org.apache.tomcat.embed:tomcat-embed-core:jar:8.5.5:com 
pile 

| +- org.apache.tomcat.embed:tomcat-embed-el:jar:8.5.5:compi 
le 

| \- org.apache.tomcat.embed:tomcat-embed-websocket:jar:8.5. 
5:compile 

*- org.hibernate:hibernate-validator:jar:5.2.4.Final:compile 

| +- javax.validation:validation-api:jar:1.1.0.Final:compile 

| +- org.jboss.logging:jboss-logging:jar:3.3.0.Final:compile 

| \- com.fasterxml:classmate:jar:1.3.1:compile 

+- com.fasterxml.jackson.core: jackson-databind: jar:2.8.3:comp 
ile 

| +- com.fasterxml.jackson.core:jackson-annotations:jar:2.8. 
3:compile 

| \- com.fasterxml.jackson.core:jackson-core: jar:2.8.3:compi 
le 

*- org.springframework:spring-web:jar:4.3.3.RELEASE:compile 

| +- org.springframework:spring-aop:jar:4.3.3.RELEASE:compil 


| +- org.springframework:spring-beans:jar:4.3.3.RELEASE: comp 


| \- org.springframework:spring-context:jar:4.3.3.RELEASE: CO 
mpile 
\- org.springframework:spring-webmvc:jar:4.3.3. RELEASE: compil 
e 
\- org.springframework:spring-expression:jar:4.3.3.RELEASE 
: compile 


这 其 中 包括 Tomcat web 服 务 器 和 Spring Boot El ¥ ° 


Spring Boot 推荐 的 基础 POM 文件 


名 称 
spring-boot-starter 
spring-boot-starter- 


amqp 


spring-boot-starter- 
aop 


spring-boot-starter- 
batch 


spring-boot-starter- 
data-jpa 


spring-boot-starter- 
data-mongodb 


spring-boot-starter- 
data-rest 


spring-boot-starter- 
jdbc 


spring-boot-starter- 
security 


spring-boot-starter- 
test 


spring-boot-starter- 
velocity 


spring-boot-starter- 
web 


spring-boot-starter- 
websocket 


spring-boot-starter-ws 


spring-boot-starter- 
actuator 


spring-boot-starter- 
remote-shell 


spring-boot-starter- 
jetty 


说 明 


核心 POM， 包 含 自动 配置 支持 、 日 志 库 和 对 YAML 
配置 文件 的 支持 。 


通过 spring-rabbit 支持 AMQP ° 


包含 spring-aop 和 AspectJ 来 支持 面向 切面 编程 
(AOP) 。 


支持 Spring Batch， 包 含 HSQLDB ° 


包含 spring-data-jpa、spring-orm 和 Hibernate 来 支 
持 JPA。 


包含 spring-data-mongodb 来 支持 MongoDB ° 


通过 spring-data-rest-webmvc 支持 以 REST 方式 暴 
露 Spring Data 仓库 。 


支持 使 用 JDBC 访问 数据 库 。 


包含 spring-security ° 


包含 常用 的 测试 所 需 的 依赖 ， 如 JUnit > Hamcrest > 
Mockito 和 spring-test 等 。 


支持 使 用 Velocity 作为 模板 引擎 。 
支持 Web 应 用 开发 ， 包 含 Tomcat 和 spring-mvc ° 


支持 使 用 Tomcat 开发 WebSocket 应 用 。 


支持 Spring Web Services ° 
添加 适用 于 生产 环境 的 功能 ， 如 性 能 指标 和 监测 等 功 


能 。 


添加 远程 SSH 支持 。 


使 用 Jetty 而 不 是 默认 的 Tomcat 作为 应 用 服务 器 。 


spring-boot-starter- 添加 Log4j 的 支持 。 


log4j 

Spa Ole anor: 使 用 Spring Boot 默认 的 日 志 框 架 Logback ° 
logging 

P MEE 使 用 Spring Boot 默认 的 Tomcat 作为 应 用 服务 器 。 


所 有 这 些 POM 依赖 的 好 处 在 于 为 开发 Spring 应 用 提供 了 一 个 良好 的 基础 。Spring 
Boot 所 选择 的 第 三 方 库 是 经 过 考虑 的 ， 是 比较 适合 产品 开发 的 选择 。 但 是 Spring 
Boot 也 提供 了 不 同 的 选项 ， 比 如 日 志 框 架 可 以 用 Logback 或 Log4j， 应 用 服务 器 可 
以 用 Tomcat 或 Jetty。 


生成 Maven 工 程 
对 于 普通 的 Java 项 目 或 者 Java Web 项 目 可 以 使 用 下 面 的 命令 创建 maven 结 构 : 


mvn archetype:generate -DgroupId=com.example -DartifactId=myproj 
ect -DarchetypeArtifactId=maven-archetype-webapp -DinteractiveMo 
de=false 


下 表 是 以 上 参数 的 使 用 说 明 : 


参数 说 明 
mvn ‘ : 
X des 
archetype:generate 固定 格式 
-Dgroupld 组 织 标识 (GAZ) 
-Dartifactld 项 目 名 称 


指定 Archetypeld，maven-archetype-quickstart， 创 建 
一 个 Java Project ; maven-archetype-webapp， 创 建 一 
个 Web Project 


-DinteractiveMode 是 否 使 用 交互 模式 


DarchetypeArtifactld 


这 将 生成 以 下 的 目录 结构 : 


L— myproject 


— pom. xml 
L— src 


L— main 
I— resources 
L— webapp 
|— WEB-INF 
| L— web.xml 
L— index.jsp 


6 directories, 3 files 


对 于 Spring Boot 项 目 ， 无 法 使 用 mvn 命令 直接 生成 ， 需 要 手动 创建 目录 : 


mkdir -p src/main/java 


创建 示例 代码 


创建 src/main/java/Example.java 文件 内 容 如 下 : 


import org.springframework.boot.*; 

import org.springframework.boot.autoconfigure.*; 
import org.springframework.stereotype.*; 

import org.springframework.web.bind.annotation.*"; 


QRestController 
QEnableAutoConfiguration 
public class Example { 


QRequestMapping("/") 
String home() { 

return "Hello World!"; 
} 


public static void main(String[] args) throws Exception { 
SpringApplication.run(Example.class, args); 


} 


e @RestController 注解 告诉 Spring 以 字符 串 的 形式 浑 染 结果 ， 并 直接 返回 给 
调用 者 。 

e @EnableAutoConfiguration 注解 告诉 Spring Boot 根 据 添 加 的 jar 依 赖 猜 测 你 
想 如 何 配置 Spring。 由 于 spring-boot-starter-web 添加 了 Tomcat 和 Spring 


MVC， 所 以 auto-configuration 将 假定 你 正在 开发 一 个 web 应 用 ， 并 对 Spring 进 
行 相应 地 设置 。 

e @RequestMapping 注解 提供 路 由 信息 ， 它 告诉 Spring 任何 来 自 "/" 路 径 的 
HTTP 请 求 都 应 该 被 映射 到 home s o 


i£: @RestController 和 @RequestMapping 是 Spring MVC 中 的 注解 (它们 不 
是 Spring Boot 的 特定 部 分 ) 。 

编译 和 发 布 

运行 该 项 目 有 以 下 两 种 方式 。 


方式 1 : 直接 mvn 命 令 运行 


mvn spring-boot:run 


方式 2 : 编译 打包 成 可 执行 jar 包 


mvn package 
java -jar target/myproject-0.0.1-SNAPSHOT. jar 


不 论 使 用 哪 种 方式 编译 ， 访 问 可 以 看 到 web 页 面 上 显示 Hello world! 。 


在 target 目录 下 ， 你 应 该 还 能 看 到 一 个 很 小 的 名 为 myproject-0.0.1- 
SNAPSHOT. jar.original 的 文件 ， 这 是 在 Spring Boot 重 新 打包 前 ，Maven 创 建 的 
原始 jar 文 件 。 实 际 上 可 运行 jar 包 中 包含 了 这 个 小 的 jar 包 


e Spring 官 方 网 站 

e Spring core technologies - spring.io 

e Spring Boot 一 一 开发 新 一 代 Spring Java™ M 

e Spring MVC 快 速 入 门 教 程 

e Spring Boot Reference Guide 中 文 翻译 - (Spring Boot 参 考 指南 》 
e 使 用 Spring Boot 快速 构建 Spring 框架 应 用 

e maven3 常 用 命令 、java 项 目 搭建 、web 项 目 搭建 详细 图 解 

e Servlet 教 程 - runoob.com 


e AOP - Aspect Oriented Programming - spring.io 
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Service Mesh 服务 网 格 


Service mesh 又 译作 "服务 网 格 “， 作 为 服务 间 通 信 的 基础 设施 层 。Buoyant 公司 的 
CEO Willian Morgan 在 他 的 这 篇 文章 WHAT'S A SERVICE MESH? AND WHY DO 
| NEED ONE? 中 解释 了 什么 是 Service Mesh， 为 什么 云 原生 应 用 需要 Service 
Mesh ° 


A service mesh is a dedicated infrastructure layer for handling service-to- 
service communication. It’s responsible for the reliable delivery of requests 
through the complex topology of services that comprise a modern, cloud 
native application. In practice, the service mesh is typically implemented as 
an array of lightweight network proxies that are deployed alongside 
application code, without the application needing to be aware. 


今年 来 以 Istio 和 Linkderd 为 代表 的 Service Mesh HRR » KAMA P-KES 
异 构 微服 务 架 构 的 王者 之 范 ， 今 天 又 碰巧 看 到 了 Red Hat 的 Burr Sutter 提出 了 8 
Steps to Becoming Awesome with Kubernetes， 整 个 PPT 一 共 60 多 页 ， 很 有 建 
设 性 ， 点 此 跳 转 到 我 的 GitHub 上 下 载 ， 我 将 其 归档 到 cloud-native-slides-share 中 
d 








original http://bit.ly/8stepsawesome 
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E RGA 4 30 FE fik Istiof& 39i sib A W service mesh 很 好 的 解决 了 异 构 语言 中 的 很 多 问 
题 ， 而 且 是 kuberentes service 上 层 不 可 或 缺 的 服务 间 代 理 。 关 于 istio 的 更 多 内 容 
请 参考 istio 中 文 文档 。 


什么 是 service mesh ? 


Service mesh 有 如 下 几 个 特点 : 


e 应 用 程序 间 通 讯 的 中 间 层 

e 轻 量 级 网 络 代理 

e 应 用 程序 无 感知 

e 解 耦 应 用 程序 的 重 试 /起 时、 监控 、 追 踪 和 服务 发 现 


目前 两 款 流行 的 service mesh 开源 软件 Istio 和 Linkerd 都 可 以 直接 在 kubernetes 
中 集成 ， 其 中 Linkerd 已 经 成 为 CNCF 成 员 。 


理解 Service Mesh 


如 果 用 一 句 话 来 解释 什么 是 Service Mesh， 可 以 将 它 比 作 是 应 用 程序 或 者 说 微服 务 
间 的 TCP/IP， 负 责 服务 之 间 的 网 络 调用 、 限 流 、 熔 断 和 监控 。 对 于 编写 应 用 程序 
来 说 一 般 无 须 关 心 TCP/IP 这 一 层 (比如 通过 HTTP 协议 的 RESTful 应 用 ) ， 同 样 
使 用 Service Mesh 也 就 无 须 关 系 服务 之 间 的 那些 原来 是 通过 应 用 程序 或 者 其 他 框 
架 实现 的 事情 ， 比 如 Spring Cloud ` OSS ， 现 在 只 要 交 给 Service Mesh 就 可 以 
Sha 


Phil Calcado 在 他 的 这 篇 博客 Pattern: Service Mesh 中 详细 解释 了 Service Mesh 
的 来 龙 去 脉 : 


.从 最 原始 的 主机 之 间 直 接 使 用 网 线 相 连 
.网络 层 的 出 现 
.集成 到 应 用 程序 PIS Step j 
. A AES E ERU Pb SB 85 PE Ahl HF 
.应 用 程序 的 中 集成 服务 发 现 和 断路 器 

.出 现 了 专门 用 于 服务 发 现 和 断路 器 的 软件 包 / 库 ， 如 Twitter 的 Finagle 和 


ES 


m 


OORA WN — 


Facebook 的 Proxygen， 这 时 候 还 是 集成 在 应 用 程序 内 部 

7. 出 现 了 专门 用 于 服务 发 现 和 断路 器 的 开源 软件 ， 如 Netflix OSS ^ Airbnb 的 
synapse 和 nerve 

8. 最 后 作为 微服 务 的 中 间 层 service mesh 出 现 


Service mesh 的 架构 如 下 图 所 示 : 


Service Mesh’s 
Control Plane 


Computer A Computer B 








Service A Sidecar Sidecar Service B 


Flow Control Flow Control 


Networking Networking 
Stack Stack 











图 片 - Service Mesh 架构 图 


图 片 来 自 : Pattern: Service Mesh 


Service mesh 作为 sidecar 运行 ， 对 应 用 程序 来 说 是 透明 ， 所 有 应 用 程序 间 的 流量 
都 会 通过 它 ， 所 以 对 应 用 程序 流量 的 控制 都 可 以 在 serivce mesh 中 实现 。 


Service mesh 如 何 工作? 


下 面 以 Linkerd 为 例 讲 解 service mesh 如 何 工 作 ，lstio 作为 service mesh 的 另 一 
种 实现 原理 与 linkerd 基本 类 似 ， 后 续 文章 将 会 详解 lstio 和 Linkerd 如 何在 
kubernetes 中 工作 。 


1. Linkerd 将 服务 请 求 路 由 到 目的 地 址 ， 根 据 中 的 参数 判断 是 到 生产 环境 、 测 试 
环境 还 是 staging 环境 中 的 服务 (服务 可 能 同时 部 署 在 这 三 个 环境 中 ) ， 是 路 
由 到 本 地 环境 还 是 公有 云 环境 ?所 有 的 这 些 路 由 信息 可 以 动态 配置 ， 可 以 是 全 
局 配置 也 可 以 为 某 些 服务 单独 配置 。 

2. 当 Linkerd 确认 了 目的 地 址 后 ， we ， 在 
kubernetes 中 是 service， 然 后 service 会 将 服务 转发 给 后 端 us 实例 。 

3. Linkerd 根据 它 观 测 到 最 近 请 求 的 延迟 时 间 ， 选 择 Hove 用 程序 的 实例 中 响 

最 快 的 实例 。 

4. Linkerd 将 请 求 发 送 给 该 实例 ， 同 时 记录 响应 类 型 和 延迟 数据 。 

5, 如 果 该 实例 挂 了 、 a 1 或 者 进程 不 工作 了 ，Linkerd 将 把 请 求 发 送 到 其 他 
实例 上 重 试 。 

6. 如 果 该 实例 持续 返回 error’ Linkerd 会 将 该 实例 从 负载 均衡 池 中 移 除 ， 稍 后 再 
周期 性 得 重 试 。 

7. 如 果 请 求 的 截止 时 间 已 过 ，Linkerd 主动 失败 该 请 求 ， 而 不 是 再 次 尝试 添加 负 
载 。 

8. Linkerd 以 metric 和 分 布 式 追踪 的 形式 捕获 上 述 行为 的 各 个 方面 ， 这 些 追 踪 信 
息 将 发 送 到 集中 metric 系统 。 


为 何 使 用 service mesh? 


Service mesh 并 没有 给 我 们 带 来 新 功能 ， 它 是 用 于 解决 其 他 工具 已 经 解决 过 的 问 
， 只 不 过 这 次 是 在 Cloud Native 的 kubernetes 环境 下 的 实现 。 


在 传统 的 MVC 三 层 Web 应 用 程序 架构 下 ， 服 务 之 间 的 通讯 并 不 复杂 ， 在 应 用 程序 
内 部 自己 管理 即 可 ， 但 是 在 现今 的 复杂 的 大 型 网 站 情况 下 ， 单 体 应 用 被 分 解 为 众多 
的 微服 务 ， 服 务 之 间 的 依赖 和 通讯 十 分 复杂 ， 出 现 了 twitter 开发 的 ERE ` 
Netflix 开发 的 Hystrix 和 Google 的 Stubby 这 样 的 "IES P 3" 库 ， 这 些 就 是 早期 的 
service mesh， 但 是 它们 都 近 适 用 于 特定 的 环境 和 特定 的 开发 语言 ， 并 不 能 作为 平 
台 级 的 service mesh 支持 。 


在 Cloud Native 架构 下 ， 容 器 的 使 用 给 予 了 异 构 应 用 程序 的 更 多 可 行 性 ， 
kubernetes 增强 的 应 用 的 横向 扩容 能 力 ， 用 户 可 以 快速 的 编排 出 复杂 环境 、 复 杂 

赖 关 系 的 应 用 程序 ， 同 时 开发 者 又 无 须 过 分 关心 应 用 程序 a 
IL Fe Zr Ap A38 3g d EK Rnt ATEENA’ MPHRA BS HAH o 


Istio VS Linkerd 


4 ay 49 Service Mesh 实 现 主要 有 两 大 阵营 ， 要 给 是 Linkerd (也 是 最 初 提出 该 概念 
的 ) ， 另 一 个 是 lstio， 当 然 还 有 很 多 其 他 号 称 也 是 Service Mesh > Hide Nginx H 3 
的 Nginmesh 。 


Feature Istio Linkerd 
部 署 架 构 Envoy/Sidecar DaemonSets 
多 用 性 RR 简单 
支持 平台 kuberentes kubernetes/mesos/Istio/local 
当前 版 本 0.3.0 leo 
是 否 已 有 生产 部 署 T 是 


下 图 是 lstio 和 Linkerd 架 构 的 不 同 ，lstio 是 使 用 Sidecar 模 式 ， 将 Envoy 植 入 到 Pod 
中 ， 而 Linkerd 则 是 在 每 台 node 上 都 以 DaemonSet 的 方式 运行 。 


Service Mesh 服务 网 格 








Istio vs Linkerd 


Istio Linkerd 








https://jimmysong.io 





图 片 - Istio vs linkerd 


关于 lstio 和 Linkerd 的 详细 信息 请 参考 安装 并 试用 lstio service mesh 5 Linkerd 使 
用 指南 。 


另外 出 品 Linkerd 的 公司 buoyant 又 推出 了 conduit， 这 是 一 种 更 轻 量 级 的 Service 
Mesh ° 


参考 


e WHAT'S A SERVICE MESH? AND WHY DO I NEED ONE? 
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Service Mesh 服务 网 格 


So what even is a Service Mesh? Hot take on Istio and Linkerd 
linkerd: A service mesh for AWS ECS 
Introducing Istio: A robust service mesh for microservices 


Application Network Functions With ESBs, API Management, and Now.. 


Service Mesh? 
Pattern: Service Mesh 
Istio'E Zr 3: P THR 
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Istio 简介 


lstio 是 由 Google、IBM 和 Lyft 开 源 的 微服 务 管理 、 保 护 和 监控 框架 。|stio 为 希腊 语 ， 
意思 是 ”起航 "。 关 于 |stio 的 详细 信息 请 参考 |stio 官 方 文档 和 |stio 中 文 文档 。 


TL;DR 关于 lstio 中 的 各 个 组 件 和 一 些 关键 信息 请 参考 下 面 的 mindmap 。 


Istio 


Mixer 


流量 管理 规则 


source https:/jimmysog.io 


用 来 对 接 不 同 的 基础 设施 后 端 
可 接 入 各 种 adapter 














用 来 做 日 志 、 度 量 、 配 额 





定义 了 两 个 方法 : 


资源 对 象 


handler 


instance 


rule 


Om 


理 员 操作 入 口 


Check 和 Report 
类 似 kubernetes 的 YAML 格 式 定 义 
分 别 根据 每 个 适配器 和 模板 来 设置 


配置 好 的 适配器 ， 里 面包 含 需要 对 输入 的 请 求 的 各 种 检查 参数 和 限制 


用 来 映射 请 求 中 的 属性 ， 作 为 适配器 的 输入 ， 例 如 metric 





配置 instance 调 用 handler 的 条 件 


定义 了 一 组 流量 规则 配置 API 

对 接 Sidecar 的 API 

通过 adapter 对 接 各 种 后 端 

不 提供 DNS， 使 用 基础 设施 提供 的 DNS， 如 kube-dns 


RBAC 


TLS 


namespace-level 
service-level 
method-level 
双向 TLS 认 证 
根据 service account 来 分 配 权限 
每 个 pod 都 具有 一 个 SA 的 SPIFFE 


SPIFFE 格 式 : spiffe://<domain>/ns/<namespace>/sa/<serviceaccount> 


name.namespace.doman 

可 以 限定 调用 来 源 和 目的 地 、 版 本 、http header 
超时 和 重 试 

在 请 求 路 径 中 注入 故障 

规则 包含 优先 级 precedence 


目的 地 
熔断 器 


策略 


Egress 规 则 


round robin 


Load Balancer lstio 仅 支持 3 种 LB 算 法 random 


Ingress and Egress 复 用 为 网 关 
timeout 
重 试 机 制 和 重 试 抖动 
故障 恢复 机 制 并 发 请 求 连接 数 和 上 游 服 务 请 求 数 限制 
负载 均衡 池 实 例 的 周期 健康 检查 
细 粒 度 熔断 器 


图 片 - /stio 的 mindmap 


weighted least request 
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使 用 istio 可 以 很 简单 的 创建 具有 负载 均衡 、 服 务 间 认 证 、 监 控 等 功能 的 服务 网 络 ， 
而 不 需要 对 服务 的 代码 进行 任何 修改 。 你 只 需要 在 部 署 环境 中 ， 例 如 Kubernetes 的 
pod 里 注入 一 个 特别 的 sidecar proxy 来 增加 对 istio 的 支持 ， 用 来 截获 微服 务 之 间 的 网 
络 流量 S 


目前 版 本 的 istio 只 支持 kubernetes， 未 来 计划 支持 其 他 其 他 环境 。 


另外 ，lstio 的 前 身 是 IBM 开 源 的 Amalgam8， 追 本 溯源 ， 我 们 来 看 下 它 的 特性 。 


Amalgam8 


Amalgam8 的 网 站 上 说 ， 它 是 一 个 Content-based Routing Fabric for Polyglot 
Microservices， 简 单 、 强 大 且 开 源 。 


Amalgam8 是 一 款 基于 内 容 和 版 本 的 路 由 布局 ， 用 于 集成 多 语言 异 构 体 微服 务 
control plane API 可 用 于 动态 编程 规则 ， 用 于 在 正在 运行 的 应 用 程序 We 
行路 由 和 操作 请 求 。 


以 内 容 /版 本 感知 方式 路 由 请 求 的 能 力 简化 了 DevOps 任 务 ， 如 金 丝 乱 和 红 / 黑 发 布 ， 
AIB Test 和 系统 地 测试 弹性 微服 务 。 


可 以 使 用 Amalgam8 和 平台 与 受 欢迎 的 容 med 时 (如 Docker > Kubernetes ， 
Marathon / Mesos) 或 其 他 云 计 算 提 供 商 (如 IBM Bluemix * Google Cloud 
Platform 或 Amazon AWS) 。 


特性 


使 用 istio 的 进行 微服 务 管理 有 如 下 特性 : 


e 流量 管理 : 控制 服务 间 的 流量 和 API 调 用 流 ， 使 调用 更 可 靠 ， 增 强 不 同 环境 下 


e 服务 识别 和 安全 : 提供 在 mesh 里 的 服务 可 识别 性 和 安全 性 保护 。 


未 来 将 支持 多 种 平台 ， 不 论 是 kubernetes、Mesos、 还 是 云 。 同 时 可 以 集成 已 有 的 
ACL 上 日志、 监控 、 配 额 、 审 计 等 。 


AH 


下 面 是 |stio 的 架构 图 。 
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图 片 - /stio 架 构图 


下 图 是 lstio 中 控制 平面 与 数据 平面 的 交互 流程 图 。 


Control Plane API 




















Ee 
Control flow during 
request processing Istio-Manager Mixer | Istio-Auth 
PERS 
Config data to ' “sa 
3 Envoys Ý TLS certs 
to Envoy 






Policy checks, 
telemetry 





HTTP/1.1, HTTP/2, 
gRPC, TCP with or 
without TLS 


|. HTTP/1.1, HTTP/2, |. | 


gRPC, TCP with or 
without TLS 








Envoy 




















Service A Service B 


图 片 - /stio 的 控制 平面 和 数据 平面 


lstio 架 构 分 为 控制 平面 和 数据 平面 。 


e 数据 平面 : 由 一 组 智能 代理 (Envoy) 作为 sidecar 部 署 ， 协 调和 控制 所 有 
microservices 之 间 的 网 络 通信 。 
e 控制 平面 : 负责 管理 和 配置 代理 路 由 流量 ， 以 及 在 运行 时 执行 的 政策 。 


Envoy 


lstio 使 用 Envoy 代 理 的 扩展 版 本 ， 该 代理 是 以 C++ 开发 的 高 性 能 代理 ， 用 于 调解 
service mesh 中 所 有 服务 的 所 有 入 站 和 出 站 流量 。|stio 利 用 了 Envoy 的 许多 内 置 功 
PE * item SIRF AM ARP MH TLS > HTTP/2&gRPCKE » Bp ZS > 35 
行 状况 检查 ， 基 于 百分比 的 流量 拆 分 分 阶段 上 线 ， 故 障 注 入 和 丰富 指标 。 


Envoy 在 kubernetes 中 作为 pod 的 sidecar 来 部 署 。 这 人 允许 lstio 将 大 量 关 于 流量 行为 

的 信号 作为 属性 提取 出 来 ， 这 些 属性 又 可 以 在 Mixer 中 用 于 执行 策略 决策 ， 并 发 送 

给 监控 系统 以 提供 有 关 整 个 mesh 的 行为 的 信息 。 Sidecar 代 理 模 型 还 允许 你 将 |stio 
功能 添加 到 现 有 部 署 中 ， 无 需 重新 构建 或 重 写 代 码 。 更 多 信息 参见 设计 目标 。 


Mixer 


Mixer fi 3t service mesh 上 执行 访问 控制 和 使 用 策略 ， 并 收集 Envoy 代 理 和 其 他 服 
务 的 莹 测 数据 。 代 理 提 取 请 求 级 属性 ， 发 送 到 mixer 进 行 评 估 。 有 关 此 属性 提取 和 

策略 评估 的 更 多 信息 ， 请 参见 Mixer 配 置 。 混 音 器 包括 一 个 灵活 的 插件 模型 ， 使 其 
能 够 与 各 种 主机 环境 和 基础 架构 后 端 进行 接口 ， 从 这 些 细 节 中 抽象 出 Envoy 代 理 和 
lstio 管 理 的 服务 。 


Istio Manager 


Istio-Manager 用 作用 户 和 |stio 之 间 的 接口 ， 收 集 和 验证 配置 ， 并 将 其 传播 到 各 种 
lstio 组 件 。 它 从 Mixer 和 Envoy 中 抽取 环境 特定 的 实现 细节 ， 为 他 们 提供 独立 于 底层 
平台 的 用 户 服务 的 抽象 表示 。 此 外 ， 流 量 管理 规则 ( 即 通用 4 层 规则 和 七 层 
HTTP/gRPC 路 由 规则 ) 可 以 在 运行 时 通过 lstio-Manager 进 行 编程 。 


Istio-auth 


lstio-Auth 提 供 强 大 的 服务 间 和 最 终 用 户 认证 ， 使 用 相互 TLS， 内 置身 份 和 凭据 管 
理 。 它 可 用 于 升级 service mesh 中 的 未 加 密 流 量 ， 并 为 运营 商 提供 基于 服务 身份 而 

不 是 网 络 控制 的 策略 的 能 力 。 |stio 的 未 来 版 本 将 增加 细 粒 度 的 访问 控制 和 审计 ， 以 
使 用 各 种 访问 控制 机 制 ( 包括 属性 和 基于 角色 的 访问 控制 以 及 授权 hook) 来 控制 和 
监控 访问 你 服务 、API 或 资源 的 人 员 。 


参考 


e lstio 开 源 平 台 发 布 ，Google、IBM 和 Lyft 分 别 承 担 什么 角色 ? 
e Istio: 用 于 微服 务 的 服务 路 合 层 
e |stio Overview 
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安装 并 试用 lstio service mesh 


官方 文档 地 址 快速 开始 


本 文 根 据 官 网 的 文档 整理 而 成 ， 步 又 


包括 安装 istio 0.5.1 并 创建 一 个 bookinfo 的 微服 
务 来 测试 istio 的 功能 。 


文中 使 用 的 yaml| 文 件 可 以 在 kubernetes-handbook 的 manifests/istio 目录 中 找 
到 ， 如 果 镜 像 pull 失 败 ， 请 根据 官网 的 镜像 自行 修改 。 


安装 环境 


e CentOS 7.4.1708 
e Docker 17.12.0-ce 
e Kubernetes 1.8.5 


ah #25 34 
Istio 的 控制 平面 部 署 在 Kubernetes 中 的 部 署 架 构 如 下 图 所 示 。 


Deployments Istio Deployment Architecture Diagram v0.1 


Base on istio 0.7.1 





istio-mixer istio-pilot istio-ingress istio-ca 





statsd-to-prometheus 








istio-proxy istio-proxy 















prom/statsd-exporter:v0.5.0 














docker.io/istio/proxy:0.7.1 
















































































infig-volum: config-volume 15003 | 15005 | 15007 80 443. 
cmn seio ps No mets | op mis OA IEA MEE nouus 0 sourco nipsfimnysongio 
istio-mixer istio-pilot istio-pilot. 








图 片 - /stio 在 Kubernetes 中 的 部 署 架 构图 


我 们 可 以 清楚 的 看 到 lstio 控制 平面 的 几 个 组 件 的 部 署 运行 的 命令 与 开发 的 端口 ， 以 
及 端口 与 服务 之 间 的 映射 的 关系 。 
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1. 下 载 安 装 包 
下 载 地 址 : https://github.com/istio/istio/releases 


下 载 Linux 版 本 的 当前 最 新 版 安装 包 


wget https://github.com/istio/istio/releases/download/0.5.1/isti 
0-0.5.1-linux.tar.gz 


解压 后 ， 得 到 的 目录 结构 如 下 : 


o 
E 
2 


istioctl 
install 

— ansible 
consul 


I— 

— eureka 
— gcp 

I— kubernetes 
|— README. md 
L— tools 


o crH"í 

oOmimÁo 

3 0»50rt 

o UME 

ÉCuzo 
c m o 

o m 一 

3 m 

o z 

0 

H 

Oo 

z 


o 
o 
o 
x 
H 
2 
—h 
o 


CONFIG-MIGRATION.md 
helloworld 

httpbin 
kubernetes-blog 
rawvm 

README .md 

sleep 


PTT 
PTT TTT) 


ct 
o 
o 
rn. 
o 


cache buster.yaml 

deb 

githubContrib 
minikube.md 

perf istio rules.yaml 
perf k8svcs.yaml 
README. md 

rules.yml 

setup perf cluster.sh 
setup run 

update all 

vagrant 


PTT TTT TTT Trt 


从 文件 里 表 中 可 以 看 到 ， 安 装 包 中 包括 了 kubernetes 的 yaml 文 件 ， 示 例 应 用 和 安装 
模板 。 


3. 先 决 条 件 


以 下 说 明 要 求 您 可 以 访问 启用 了 RBAC (基于 角色 的 访问 控制 ) 的 Kubernetes1.7.3 
或 更 新 的 群集 。 您 还 需要 安装 1.7.3 或 更 高 版 本 。 如 果 您 希望 启用 automatic sidecar 
injection， 则 需要 Kubernetes 1.9 或 更 高 版 本 。kubectl 


注意 : 如 果 您 安装 了 lstio 0.1.x， 请 在 安装 新 版 本 之 前 彻底 印 载 它 (包括 适用 于 所 有 
启用 |stio 的 应 用 程序 窗口 的 |stio 支 架 ) 。 安 装 或 升级 Kubernetes CLikubectl 4 Z ie 
群集 支持 的 版 本 (CRD 支持 版 本 为 1.7 或 更 高 版 本 ) 。 


根据 您 的 Kubernetes 提 供 者 : 
要 在 本 地 安装 lstio， 请 安装 最 新 版 本 的 Minikube (版 本 0.22.1 或 更 高 版 本 ) 。 
4.3 ae. RY 步骤 


从 0.2 版 本 开始 ，lstio 安 装 在 它 自己 的 istio-system 命 名 空间 中 ， 并 且 可 以 管理 来 自 
所 有 其 他 命名 空间 的 服务 。 


转 至 lstio 发 布 页 面 以 下 载 与 您 的 操作 系统 相对 应 的 安装 文件 。 如 果 您 使 用 的 是 
MacOS 或 Linux 系 统 ， 以 下 命令 自动 下 载 并 提取 最 新 版 本 : 


curl -L https://git.io/getLatestIstio | sh - 


文件 并 将 目录 更 改 为 文件 位 置 。 


Installation .yaml Kubernetes 的 安装 文件 

iuo uic iut 

bin/istioctl =—##lbin/X4 在 手动 注入 Envoy 作 为 附属 代理 并 创建 路 由 规则 和 
策略 时 使 用 ， 

istio.VERSIONA E x 4F 


例如 ， 如 果 包 是 istio-0.5 (初步 ) 


cd istio-0.5 (preliminary ) 


将 istioctl 客 户 端 添加 到 您 的 PATH。 例 如 ， 在 MacOS 或 Linux 系 统 上 运行 以 下 命令 : 


export PATH-$PWD/bin:$PATH 


安装 lstio 的 核心 组 件 。 从 下 面 两 个 互相 排斥 的 选项 中 选择 一 个 ， 或 者 用 Helm Chart 
RRB: a) 安装 lstio 而 不 启用 侧 车 间 的 相互 TLS 认 证 。 为 具有 现 有 应 用 程序 的 
群集 ， 使 用 |stio 辅 助 车 的 服务 需要 能 够 与 其 他 非 lstio Kubernetes 服 务 以 及 使 用 活动 
性 和 准备 就 绪 探 测 器 ， 无 头 服务 或 StatefulSets 的 应 用 程序 通信 的 应 用 程序 选择 此 选 
项 o 


kubectl apply -f install/kubernetes/istio.yaml 
BA 
b) 安装 lstio 并 启用 侧 柜 之 间 的 相互 TLS 认 证 : 


kubectl apply -f install/kubernetes/istio-auth.yaml 
这 两 个 选项 都 会 创建 istio-system 命 名 空间 以 及 所 需 的 RBAC 权 限 ， 并 部 署 |stio- 
Pilot > Istio-Mixer > Istio-Ingress?eIstio-CA (证 书 颁 发 机 构 ) 。 


可 选 : 如 果 您 的 群集 的 Kubernetes 版 本 是 1.9 或 更 高 ， 并 且 您 希望 启用 自动 代理 注 
入 ， 请 安装 sidecar injector webhook。 验证 安装 请 确保 以 下 Kubernetes 服 务 部 
Æ : istio-pilot > istio-mixer > istio-ingress ° 


kubectl get svc -n istio-system 


NAME CLUSTER-IP EXTERNAL - IP PORT(S) 

AGE 
istio-ingress 10.83.245.171 35.184.245.62 80:32730/TCP, 4 
43:30574/TCP 5h 
istio-pilot 10.83.251.173 <none> 8080/TCP, 8081/ 
TCP 5h 
istio-mixer 10.83.244.253 <none> 9091/TCP, 9094/ 


TCP, 42422/TCP 5h 


主意 : 如 果 您 的 集群 中 不 支持 外 部 负载 平衡 《例如 ，Minikube) 的 环境 中 运 


运 
行 ， 该 external-ip 的 istio-ingress 会 显示 。 您 必须 io 用 NodePort 访 问 应 用 程序 ， 
或 使 用 端口 转发 。 


修改 istio.yaml 中 的 istio-ingress service 的 type 为 ClusterIP， 并 设置 nodePort > 9k 
ThA 32000 ° 


确保 相应 Kubernetes 容 器 都 运行 起 来 : istio-pilot-* ^ istio-mixer- 


* ^ istio-ingress-* ^ istio-ca-* ， 和 可 选 的 istio-sidecar-injector- 


* o 


kubectl get pods -n istio-system 


istio-ca-3657790228-j21b9 1/1 Running 0 
AE rene dea TE 1/1 Running 0 
—€— —— 1/1 Running 0 
T 1/1 Running 0 
ee m 2/2 Running 0 
5h 
部 署 您 的 应 用 程序 


您 现在 可 以 部 署 您 自己 的 应 用 程序 或 者 像 Bookinfo 一 样 随 安装 提供 的 示例 应 用 程序 
之 一 。 注 意 : 应 用 程序 必须 对 所 有 HTTP 通 信使 用 HTTP/1.1 或 HTTP/2.0 协 议 ， 因 为 
HTTP/1.0 不 受 支持 。 


如 果 您 启动 了 lstio-sidecar-injector， 如 上 所 示 ， 您 可 以 直接 使 用 应 用 程序 部 署 应 用 
程序 kubectl create ° 


Istio Sidecar 注 入 器 会 自动 将 Envoy 容 器 注入 到 您 的 应 用 程序 窗 格 中 ， 假 设 运 行 在 标 
有 名 称 空间 的 名 称 空间 中 istio-injection-enabled 


kubectl label namespace <namespace> istio-injection=enabled 


kubectl create -n <namspace> -f <your-app-spec>.yaml 


如 果 您 没有 安装 lstio-sidecar- injector ， 则 在 部 署 它们 之 前 ， 必 须 使 用 istioctl kube- 
inject 将 Envoy 容 器 手动 注入 应 用 程序 窗 格 中 : 


kubectl create -f <(istioctl kube-inject -f <your-app-spec>.yam1) 


«| mmm a) 





5p 3X, 


sr zx Istio sidecar3t4£ 35 : 


4o JK f& à fl Istio-sidecar-injector » 35 35 Hap 3, : 


kubectl delete -f install/kubernetes/istio-sidecar-injector-with 
-ca-bundle.yaml 


卸载 Istio 核 心 组 件 。 对 于 0.6 (初始 ) 发 行 版 ， ese eo ' istio-system 
命名 空间 和 分 层 下 的 所 有 资源 。 和 忽略 不 存在 资源 的 错 i 全 的 ， 因 为 它们 可 能 
被 分 层 删除 。 


a) 如 果 您 在 禁用 相互 TLS 身 份 验证 的 情况 下 安装 了 lstio : 
kubectl delete -f install/kubernetes/istio.yaml 
BZ 
b) 如 果 您 在 启用 相互 TLS 身 份 验证 的 情况 下 安装 了 lstio : 
kubectl delete -f install/kubernetes/istio-auth.yaml 
7. 安 装 监控 插件 
安装 插件 


kubectl apply -f install/kubernetes/addons/prometheus.yaml 
kubectl apply -f install/kubernetes/addons/grafana. yaml 
kubectl apply -f install/kubernetes/addons/servicegraph.yaml 
kubectl apply -f install/kubernetes/addons/zipkin.yaml 


在 traefik ingress 中 增加 增加 以 上 几 个 服务 的 配置 ， 同 时 增加 istio-ingress 配 置 。 


- host: grafana.istio.io 


http: 
paths: 
- path: / 
backend: 


serviceName: grafana 
servicePort: 3000 
- host: servicegraph.istio.io 


http: 
paths: 
- path: / 
backend: 


serviceName: servicegraph 
servicePort: 8088 
- host: prometheus.istio.io 


http: 
paths: 
- path: / 
backend: 


serviceName: prometheus 
servicePort: 9090 
- host: zipkin.istio.io 


http: 
paths: 
- path: / 
backend: 


serviceName: zipkin 
servicePort: 9411 
- host: ingress.istio.io 


http: 
paths: 
- path: / 
backend: 


serviceName: istio-ingress 
servicePort: 80 


测试 
我 们 使 用 lstio 提 供 的 测试 应 用 bookinfo 微 服务 来 进行 测试 。 


该 微服 务 用 到 的 镜像 有 : 


istio/examples-bookinfo-details-v1i 
istio/examples-bookinfo-ratings-vi 
istio/examples-bookinfo-reviews-vi 
istio/examples-bookinfo-reviews-v2 
istio/examples-bookinfo-reviews-v3 
istio/examples -bookinfo-productpage-v1i 





该 应 用 架构 图 如 下 : 
$ eus 
Java ) 
Envoy : 

: i 

& python | —— | 
= EB 

有 : Reviews-v2 : 
:| Dock | 





M : H [Ratings | S 
Ingress Envoy f |i 9 | 


: NC y 
Reviews-v3| | : 
太太 太太 」 | 


po les 














| 
\e— / 


E A - Booklnfo Sample E M 7&3 A 


部 署 应 用 


kubectl create -f <(istioctl kube-inject -f samples/apps/bookinf 
0/bookinfo.yaml) 


Istio kube-inject 命令 会 在 bookinfo.yaml 文件 中 增加 Envoy sidecar 信 
息 。 参 考 : https://istio.io/docs/reference/commands/istioctl.html#istioctl-kube- 
inject 
在 本 机 的 /etc/hosts 下 增加 VIP 节点 和 ingress.istio.io 的 对 应 信息 ， 具 体 
步骤 参考 : 边缘 节点 配置 ， 或 者 使 用 gateway ingress 来 访问 服务 ， 


如 果 将 productpage 配置 在 了 ingress 里 了， 那么 在 浏览 器 中 访问 
http://ingress.istio.io/productpage °> 4 R44 H f istio R0 8€) gateway ingress 配 置 
AJTE » ingress service 使 用 nodePort 方式 暴露 的 默认 使 用 32000 端 口 ， 那 么 可 以 
使 用 http:// 任 意 节点 的 IP:32000/productpage 来 访问 。 





The Comedy of Errors 
Wikipedia Summary: The Comedy of Errors is one of William Shakespeare's early plays. It is his shortest and one of his most farcical comedies, with a major part of the humour coming from slapstick and mistaken identity, in addition to puns and word 
play. 


Book Details An extremely entertaining play by Shakespeare. The slapstick humour is refreshing! 

Paperback: — Reviewer1 Affiliation? 
200 pages tok 
Publisher: 
PublisherA 
Languag , A 
English Absolutely fun and entertaining. The play lacks thematic depth when compared to other plays 
ISBN-10: by Shakespeare. 
Bone Reviwer2Afiation2 

1 Jooloicx 


123-1234567980 


E HA - Booklnfo Sample 5i ® 


多 次 刷新 页 面 ， 你 会 发 现 有 的 页 面 上 的 评论 里 有 星 级 打分 ， 有 的 页 面 就 没有 ， 这 是 
因为 我 们 部 署 了 三 个 版 本 的 应 用 ， 有 的 应 用 里 包含 了 评分 ， 有 的 没有 。lstio 根 据 默 
认 策 略 随机 将 流量 分 配 到 三 个 版 本 的 应 用 上 。 


查看 部 署 的 bookinfo 应 用 中 的 productpage-vi service 和 deployment， 查 
看 productpage-vi 的 pod 的 详细 json 信 息 可 以 看 到 这 样 的 结构 : 


$ kubectl get pod productpage-v1-944450470-bd530 -o json 


见 productpage-v1-istio.json 文 件 。 从 详细 输出 中 可 以 看 到 这 个 Pod 中 实际 有 两 个 容 
器 ， 这 里 面包 括 了 initcontainer ， 作 为 istio 植 入 到 kubernetes deployment 中 的 
sidecar ° 


"initContainers": [ 


{ 

"args": [ 
"p", 
"15001", 
vag 
"1331" 

], 


"image": "docker.io/istio/init:0.1", 
"imagePullPolicy": "Always", 

"name": "init", 

"resources": {}, 


安装 并 试用 |stio service mesh 


"securityContext": { 
"capabilities": { 


"add": [ 
"NET ADMIN" 
] 
} 
ty 
"terminationMessagePath": "/dev/termination-log", 
"terminationMessagePolicy": "File", 
"volumeMounts": [ 
{ 
"mountPath": "/var/run/secrets/kubernete 


s.io/serviceaccount", 
"name": "default-token-319f0", 
"readOnly": true 


"args": [ 
n" -c", 
"sysctl -w kernel.core_pattern=/tmp/core.%e. 
%p.%t Nu0026Nu0026 ulimit -c unlimited" 
], 
"command": [ 
"/bin/sh" 
], 
"image": "alpine", 
"imagePullPolicy": "Always", 
"name": "enable-core-dump", 
"resources": (3, 
"securityContext": ( 
"privileged": true 


ty 

"terminationMessagePath": "/dev/termination-log", 
"terminationMessagePolicy": "File", 
"volumeMounts": [ 


( 


s.io/serviceaccount", 


"mountPath": "/var/run/secrets/kubernete 


"name": "default-token-319f0", 
"readOnly": true 


1032 


不 断 刷新 productpage 页 面 ， 将 可 以 在 以 下 几 个 监控 中 看 到 如 下 界面 。 


Grafana 页 面 


24 \stio Dashboard - € < Zoomout > OUast5 minutes 


Source All~ Target All ~ All + Version — Al [CI 


À Istio Istio is an open platform that provides a uniform way to connect, manage, and secure microservices. 
Need help? Join the lstio community. 


Global Request Volume Global Success Rate (non-5xx responses) 4xxs 5xxs 


0.3 ops | 100% N/A N/A 


Service Mesh 


Request Volume Success Rate by Service (non-5xx responses) $ 4xxs by Service 5xxs by Service 
100.00% 


No datapoints © No datapoints @ 


13:57 13:58 :00 13:58 13:59 13:57 14:00 14:01 D : 14:00 
All = 200s details 一 productpage — ratings 


Services 


details 


Requests by Source, Version, and Response Code Success Rate by Source and Version (non-5xx responses) ^ Response Time by Source and Version : Response Size by Source and Version 
1.5 ops 100.00% 


75.00% = — 
1.0 ops No datapoints © 


50.00% 
0.5 ops 
n 25,00% 
Oops | 1% 
1357 1358 13:59 1357 13:58 1359 14:00 1401 13:57 13:58 1359 14:00 14:01 13:59 14:00 1401 


productpage -» v1 : 200 productpage -» vi productpage-» vi(p50) 一 productpage -> v1 (p90) 
= productpage > vi(p95) — productpage -> v1 (p99) 


reviews 





& A - /stio Grafana 界 面 


Prometheus 页 面 


metheus 





Load time: 124ms 
request, count Resolution: 14s 


Graph Console 


bl 1h * « until » Res. (s) O stacked 


60 

















request count(nstance: 
li request. count(instance 
request. count(instance 
request count(instance-"istio-mixer:42422" job-"mixer" method-"/ratings",response code-"200" service-"ratings",source-"reviews" larget-"ratings. default svc.cluster.local" version-"v1") 
"mixer" method-"/productpage" response codez"200",service-"productpage" source-"unknown",target-"productpage.default.svc.cluster.local" versio 


request. count(instance-"istio-mixer:42422" job: 
request. count(instance-"istio-mixer:42422" job-" 302" service-"productpage",source-"unknown" target-"productpage.defaull.svc.cluster.local" version-"v1") 
request. count(instance-"istio-mixer:42422" job="mi i Y ice-"productpage" source-"unknown" target="productpage. default. svc.cluster.local",version="v1"} 
request. count(instance-' s x x É 'details.default.svc:cluster.local",version="v1"} 
request_count{instance="isti z ib Y T) 





Remove Graph 


Add Graph 





A A - Prometheus i 面 


Zipkin 页 面 


http://zipkin.istio.io 





istio-proxy 7| all 7 |Starttime 06-02-2017 12:50 End time | 06-02-2017 18:50 Duration (us) >= 


Limit 10 Find Traces @ 


Showing: 10 of 10 


Sort: | Longest First 





66.057ms 4spans 
istio-proxy 100% 


64.976ms 4spans 
istio-proxy 10096 
63.186ms  4spans 
istio-proxy 10096 
62.334ms 4spans 
istio-proxy 100% 
61.548ms 4spans 
istio-proxy 100% 
60.839ms 4spans 


istio-proxy 100% 


图 片 - Zipkin 页 面 


ServiceGraph 页 面 
http://servicegraph .istio.io/dotviz 
可 以 用 来 查看 服务 问 的 依赖 关系 。 


访问 http://servicegraph.istio.io/graph 可 以 获得 json 格 式 的 返回 结果 。 






qps: 0.071186, version: v1 






productpage 


qps: 0.020339, version: v3)qps: 0.030508, version: vl \qps: 0.071186, version: v1 


qps: 0.020339, version: v2 








qps: 0.040678, version: v1 





图 片 - ServiceGraph 9i xu 


更 进一步 


Booklnfo 示 例 中 有 三 个 版 本 的 reviews ， 可 以 使 用 istio 来 配置 路 由 请 求 ， 将 流量 


分 发 到 不 同 版 本 的 应 用 上 。 参 考 Configuring Request Routing 。 


还 有 一 些 更 高 级 的 功能 ， 我 们 后 续 将 进一步 探索 。 


参考 
e Installing lstio 


e Booklnfo sample 


Copyright © jimmysong.io 2017-2018 all right reserved > powered by 
GitbookUpdated at 2018-05-09 14:15:47 


配置 请 求 的 路 由 规则 
在 上 一 节 安 装 istio 中 我 们 创建 Booklnfo 的 示例 ， 就 悉 了 |stio 的 基本 功能 ， 现 在 我 们 
再 来 看 一 下 istio 的 高 级 特性 一 ”配置 请 求 的 路 由 规则 。 


使 用 istio 我 们 可 以 根据 权重 和 HTTP headers 来 动态 配置 请 求 路 由 。 


基于 内 容 的 路 由 


因为 Booklnfo 示 例 部 署 了 3 个 版 本 的 评论 微服 务 ， 我 们 需要 设置 一 个 默认 路 由 。 S 

则 ， 当 你 多 次 访问 应 用 程序 时 ， 会 注意 到 有 时 输出 包含 星 级 ， 有 时 候 又 没有 。 这 是 
为 没有 明确 的 默认 版 本 集 ，|stio 将 以 随机 方式 将 请 求 路 由 到 服务 的 所 有 可 用 版 

本 。 

注意 : 假定 您 尚未 设置 任何 路 由 。 如 果 您 已 经 为 示例 创建 了 冲突 的 路 由 规则 ， 则 需 
要 在 以 下 命令 中 使 用 replace 而 不 是 create。 


下 面 这 个 例子 能 够 根据 网 站 的 不 同 登 陆 用 户 ， 将 流量 划分 到 服务 的 不 同 版 本 和 实 
例 。 跟 kubernetes 中 的 应 用 一 样 ， 所 有 的 路 由 规则 都 是 通过 声明 式 的 yaml 配 置 。 关 
于 reviews:vi 和 reviews:v2 的 唯一 区 别 是 ，v1 没 有 调用 评分 服务 ， 


productpage 页 面 上 不 会 显示 评分 星 标 。 


1. 将 微服 务 的 默认 版 本 设置 成 v1。 


istioctl create -f samples/apps/bookinfo/route-rule-all-vi.y 
aml 


使 用 以 下 命令 查看 定义 的 路 由 规则 。 


istioctl get route-rules -0 yaml 


type: route-rule 
name: details-default 
namespace: default 
spec: 
destination: details.default.svc.cluster.local 
precedence: 1 
route: 
- tags: 
version: vi 
type: route-rule 
name: productpage-default 
namespace: default 
spec: 
destination: productpage.default.svc.cluster.local 
precedence: 1 
route: 
- tags: 
version: vi 
type: route-rule 
name: reviews-default 
namespace: default 
spec: 
destination: reviews.default.svc.cluster.local 
precedence: 1 
route: 
- tags: 
version: vi 
type: route-rule 
name: ratings-default 
namespace: default 
spec: 
destination: ratings.default.svc.cluster.local 
precedence: 1 
route: 
- tags: 
version: vi 


由 于 对 代理 的 规则 传播 是 异步 的 ， 因 此 在 尝试 访问 应 用 程序 之 前 ， 需 要 等 待 几 
秒 钟 才 能 将 规则 传播 到 所 有 pod e 


. 在 浏览 器 中 打开 Booklnfo URL (http://$GATEWAY_URL/productpage > RAI 
在 上 一 节 中 使 用 的 是 http://ingress.istio.io/productpage ) 您 应 该 会 看 到 
Booklnfo 应 用 程序 的 产品 页 面 显示 。 注意 ， 产 品 页 面 上 没有 评分 星 ， 因 

为 reviews:vi 不 访问 评级 服务 。 


3. 将 特定 用 户 路 由 到 reviews:v2 。 


为 测试 用 户 jason 启 用 评分 服务 ， 将 productpage 的 流量 路 由 到 reviews:v2 X 
例 上 。 


istioctl create -f samples/apps/bookinfo/route-rule-reviews- 
test-v2.yaml 


确认 规则 生效 : 


istioctl get route-rule reviews-test-v2 


destination: reviews.default.svc.cluster.local 
match: 
httpHeaders: 
cookie: 
regex: ^(.*?;)?(user-jason)(;.*)?$ 

precedence: 2 
route: 
- tags: 

version: v2 


4. 使 用 jason 用 户 登 陆 productpage 页 面 。 


你 可 以 看 到 每 个 刷新 页 面 时 ， 页 面 上 都 有 一 个 1 到 5 颗 星 的 评级 。 如 果 你 使 用 其 
他 用 户 登 陆 的 话 ， 将 因 继 续 使 用 reviews:v1 而 看 不 到 星 标 评分 。 


内 部 实现 


在 这 个 例子 中 ， 一 开始 使 用 istio 将 100% 的 流量 发 送 到 Booklnfo 服 务 
的 reviews:vi 的 实例 上 。 然 后 又 根据 请 求 的 header (15149 A P & cookie) 将 流 
量 选择 性 的 发 送 到 reviews:v2 实例 上 。 


验证 了 V2 实例 的 功能 后 ， 就 可 以 将 全 部 用 户 的 流量 发 送 到 V2 实例 上 ， 或 者 逐步 的 迁 
移 流量 ， 如 10%、20% 直 到 100%。 


如 果 你 看 了 故障 注入 这 一 节 ， 你 会 发 现 V2 版 本 中 有 个 bug， 而 在 V3 版 本 中 修复 了 ， 
你 想 将 流量 迁移 到 reviews:vi 迁移 到 reviews:v3 版 本 上 ， 只 需要 运行 如 下 命 


4: 


1. 将 50% 的 流量 从 reviews:vi 转移 到 reviews:v3 上 。 


istioctl replace -f samples/apps/bookinfo/route-rule-reviews 
-50-v3.yaml 


注 
创 


意 这 次 使 用 的 是 replace 命令 ， 而 不 是 create ， 因 为 该 rule 已 经 在 前 面 
建 过 了 。 
2. 登 出 jason 用 户 ， 或 者 删除 测试 规则 ， 可 以 看 到 新 的 规则 已 经 生效 。 


删除 测试 规则 。 


istioctl delete route-rule reviews-test-v2 
istioctl delete route-rule ratings-test-delay 


现在 的 规则 就 是 刷新 productpage 页 面 ，50% 的 概率 看 到 红色 星 标的 评论 ， 
50% 的 概率 看 不 到 星 标 。 


注意 : 因为 使 用 Envoy sidecar 的 实现 ， 你 需要 刷新 页 面 很 多 次 才能 看 到 接近 规 
则 配置 的 概率 分 布 ， 你 可 以 将 v3 的 概率 修改 为 90%， 这 样 刷新 页 面 时 ， 看 到 红 
色 星 标的 概 举 更 高 。 


3， 当 V3 版 本 的 微服 务 稳定 以 后 ， 就 可 以 将 100% 的 流量 分 挫 到 reviews:v3 上 
T 


istioctl replace -f samples/apps/bookinfo/route-rule-reviews 
-v3.yaml 


现在 不 论 你 使 用 什么 用 户 登 陆 productpage 页 面 ， 你 都 可 以 看 到 带 红 色 星 标 
评分 的 评论 了 。 


Copyright © jimmysong.io 2017-2018 all right reserved * powered by 
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安装 和 拓展 Istio mesh 


前 置 条 件 


下 面 的 操作 说 明 需 要 您 可 以 访问 kubernetes 1.7.3 后 更 高 版 本 的 集群 ， 并 且 启 用 了 
RBAC (基于 角色 的 访问 控制 )。 您 需要 安装 了 1.7.3 或 更 高 版 本 的 kubectl 4 
令 。 如 果 您 希望 启用 自动 注入 sidecar， 您 需要 启用 kubernetes 集群 的 alpha 7 


注意 : 如 果 您 安装 了 lstio 0.1.x， 在 安装 新 版 本 前 请 先 HR 它们 (包括 已 启用 
Istio 应 用 程序 Pod 中 的 sidecar) 。 
e 取决 于 您 的 kubernetes 提供 商 


o 本 地 安装 |stio， 安 装 最 新 版 本 的 Minikube (version 0.22.1 或 者 更 高 )。 


o Google Container Engine 
m 使 用 kubectl 获取 证 书 〈 使 用 您 自己 的 集群 的 名 字 替 换 <cluster- 
name» ， 使 用 集群 实际 所 在 的 位 置 替换 <zone> ) 


gcloud container clusters get-credentials <cluster-na 
me> --zone <zone> --project <project-name> 


s 将 集群 管理 员 权限 授予 当前 用 户 (需要 管理 员 权 限 才 能 为 lstio 创 建 必 
要 的 RBAC 规 则 ) 


kubectl create clusterrolebinding cluster-admin-bindi 
ng --clusterrole=cluster-admin --user=$(gcloud config 
get-value core/account ) 


o IBM Bluemix Container Service 


m 使 用 kubectl 获取 证 书 (使 用 您 自己 的 集群 的 名 字 替 换 ) 


«cluster-name» 


$(bx cs cluster-config <cluster-name>|grep "export KU 
BECONFIG" ) 


o Openshift Origin 3.7 或 者 以 上 版 本 : 


m 默认 情况 下 ，Openshift 不 允许 以 UID 0 运行 容器 。 为 lstio 的 入 口 
(ingress) 和 出 口 (egress) service account 启用 使 用 UID 0 运行 的 


or 9 。 


A> as ， 


oc adm policy add-scc-to-user anyuid -z istio-ingress 
-service-account -n istio-system 

oc adm policy add-scc-to-user anyuid -z istio-egress- 
service-account -n istio-system 

oc adm policy add-sc-to-user anyuid -z default -n ist 
io-system 


m 运行 应 用 程序 Pod 的 service account 需要 特权 安全 性 上 下 文 限 制 ， 
以 此 作为 sidecar 注入 的 一 部 分 : 


oc adm policy add-scc-to-user privileged -z default - 
n <target-namespace> 


e 安装 或 升级 Kubernetes 命令 行 工 具 kubectl 以 匹配 您 的 集群 版 本 (1.7 或 以 上 
BRA) 。 


不 论 对 于 哪个 lstio 发 行 版 ， 都 安装 到 istio-system namespace 下 ， 即 可 以 管 
理 所 有 其 它 namespace 下 的 微服 务 。 


1. 到 Istio release 页 面 上 ， 根 据 您 的 操作 系统 下 载 对 应 的 发 行 版 。 如 果 您 使 用 的 
是 MacOS 或 者 Linux 系统 ， 可 以 使 用 下 面 的 额 命令 自动 下 载 和 解压 最 新 的 发 
行 版 : 


curl -L https://git.io/getLatestIstio | sh - 


2. 解压 安装 文件 ， 切 换 到 文件 所 在 目录 。 安 装 文件 目录 下 包含 : 


o install/ 目录 下 是 kubernetes 使 用 的 .yaml 安装 文件 
o samples/ 目录 下 是 示例 程序 
o istioctl 客户 端 二 进 制 文件 在 bin 目录 下 。 istioct1 文件 用 户 
手动 注入 Envoy sidecar 代理 、 创 建 路 由 和 策略 等 。 
o istio.VERSION 配置 文件 
3. 切换 到 istio 包 的 解压 目录 。 例 如 istio-0.2.7 : 


cd istio-0.2.7 


4. 将 istioctl 客户 端 二 进 制 文件 加 到 PATH 中 。 


例如 ， 在 MacOS X Linux 系统 上 执行 下 面 的 命令 : 


export PATH-$PWD/bin:$PATH 


5. 安装 lstio 的 核心 部 分 。 选 择 面 两 个 A 选项 中 的 之 一 : 
a) 安装 lstio 的 时 候 不 启用 sidecar ZA) 4) TLS 双向 认证 : 


为 具有 现在 应 用 程序 的 集群 选择 该 选项 ， 使 用 lstio sidecar 的 服务 需要 能 够 与 
非 Istio Kubernetes 服务 以 及 使 用 liveliness 和 readiness 探 针 、headless 
service 和 StatefulSet 的 应 用 程序 通信 。 


kubectl apply -f install/kubernetes/istio.yaml 
或 者 
b) 安装 lstio 的 时 候 启 用 sidecar 之 间 的 TLS 双向 认证 : 
kubectl apply -f install/kubernetes/istio-auth.yaml 
这 两 个 选项 都 会 创建 istio-system 命名 空间 以 及 所 需 的 RBAC 权限 ， 并 部 


署 Istio-Pilot ` Istio-Mixer ^ Istio-Ingress ^ Istio-Egress 和 Istio-CA (证 书 颁 发 
机 构 ) 。 


6. 可 选 的 : 如 果 您 的 kubernetes 集群 开启 了 alpha 功能 ， 并 想 要 启用 自动 注入 
sidecar， 需 要 安装 Istio-Initializer : 


kubectl apply -f install/kubernetes/istio-initializer.yaml 


验证 安装 


1. 确认 系列 kubernetes 服务 已 经 部 署 了 : istio-pilot ^ istio- 


mixer 、 istio-ingress 、 istio-egress 


kubectl get svc -n istio-system 


NAME CLUSTER - IP EXTERNAL - IP PORT(S) 
AGE 
istio-egress 10.83.247.89 <none> 80/TCP 
5h 
istio-ingress 10.83.245.171 35.184.245.62 80:32730/T 
CP, 443:30574/TCP 5h 
istio-pilot 10.83.251.173 | «none» 8080/TCP, 8 
081/TCP 5h 
istio-mixer 10.83.244.253 «none» 9091/TCP, 9 


094/TCP, 42422/TCP 5h 


注意 : 如 果 您 运行 的 集群 不 支持 外 部 负载 均衡 器 (如 minikube) >  istio- 
ingress 服务 的 EXTERNAL-IP 显示 <pending> 。 你 必须 改 为 使 用 
NodePort service 或 者 端口 转发 方式 来 访问 应 用 程序 。 

2. 确认 对 应 的 Kubernetes pod 已 部 署 并 且 所 有 的 容器 都 启动 并 运行 : istio- 
pilot-* ^ istio-mixer-* ^ istio-ingress-* ^ istio-egress- 


* ~ istio-ca-* ， istio-initializer-* 是 可 以 选 的 。 


kubectl get pods -n istio-system 


istio-ca-3657790228-j21b9 1/1 Running 0 


— — —— 1/1 Running 0 

seeder —É— 1/1 Running 0 

——— 1/1 Running 0 

oe 1/1 Running 0 

ee ene 2/2 Running 0 
5h 


部 署 应 用 


您 可 以 部 署 自己 的 应 用 或 者 示例 应 用 程序 如 Booklnfo e. 注意 : 应 用 程序 必须 使 用 
HTTP/1.1 或 HTTP/2.0 协议 来 传输 HTTP 流量 ， 因 为 HTTP/1.0 已 经 不 再 支持 。 


如 果 您 启动 了 |stio-lnitializer， 如 上 所 示 ， 您 可 以 使 用 kubectl create 直接 部 
署 应 用 。lstio-lnitializer 会 向 应 用 程序 的 pod 中 自动 注入 Envoy 容器 : 


kubectl create -f <your-app-spec>.yaml 


如 果 您 没有 安装 Istio-initializer 4976 » diede istioctl kube-inject 命令 在 部 署 应 
用 之 前 向 应 用 程序 的 pod 中 手动 注入 Envoy X 


kubectl create -f <(istioctl kube-inject -f <your-app-spec>.yaml) 
B|m—————————— —À— 9] |] 
卸载 


e jp # Istio initializer: 


如 果 您 安装 Isto 的 时 候 启 用 了 initializer > 25 Sp 2X € 


kubectl delete -f install/kubernetes/istio-initializer.yaml 


e R Istio 核心 组 件 。 对 于 某 一 lstio MA > MME RBAC 权限 ， istio- 
system namespace， 和 该 命名 空间 的 下 的 各 层级 资源 。 


不 必 理 会 在 层级 删除 过 程 中 的 各 种 报错 ， 因 为 这 些 资源 可 能 已 经 被 删除 的 。 


a) 如 果 您 在 安装 lstio 的 时 候 关闭 了 TLS 双向 认证 : 


kubectl delete -f install/kubernetes/istio.yaml 


AG 
b) 如 果 您 在 安装 lstio 的 时 候 启 用 到 了 TLS 双向 认证 : 


kubectl delete -f install/kubernetes/istio-auth.yaml 


z% Istio Sidecar 


Pod Spec 需 满足 的 条 件 


为 了 成 为 Service Mesh 中 的 一 部 分 ，kubernetes 集群 中 的 每 个 Pod 都 必须 满足 如 
下 条 件 : 


1. Service 注解 : 每 个 pod 都 必须 只 属于 某 一 个 Kubernetes Service (当前 不 支 
持 一 个 pod 同时 属于 多 个 service) 。 

2. 命名 的 端口 : Service 的 端口 必须 命名 。 端 口 的 名 字 必 须 遵 循 如 下 格式 

<protocol>[-<suffix>] ， 可 以 是 http、http2、grpc、mongo、 或 者 

redis 作为 <protocol> ， 这 样 才能 使 用 Istio 的 路 由 功能 。 例 如 name: 
http2-foo 和 name: http 都 是 有 效 的 端口 名 称 ， 而 name: http2foo 
不 是 。 如 果 端 口 的 名 称 是 不 可 识别 的 前 级 或 者 未 命名 ， 那 么 该 端口 上 的 流量 就 
会 作为 普通 的 TCP 流量 (除非 使 用 Protocol: UDP 明确 声明 使 用 UDP 端 
口 ) o 

3. 带 有 app label 的 Deployment : 我 们 建议 kubernetes 的 Deploymenet 资 
源 的 配置 文件 中 为 Pod 明确 指定 app label。 每 个 Deployment 的 配置 中 都 需 
要 有 个 不 同 的 有 意义 的 app 标签 。 app label 用 于 在 分 布 式 怪 重 中 添加 上 
下 文 信息 。 

4. Mesh 中 的 每 个 pod 里 都 有 一 个 Sidecar : 最 后 ，Mesh 中 的 每 个 pod 都 必须 


运行 与 lstio 兼容 的 sidecar。 下 面部 分 介绍 了 将 sidecar 注入 到 pod 中 的 两 种 
方法 : 使 用 istioctl 命令 行 工 具 手 动 注入 ， 或 者 使 用 istio initializer 自动 注 
入 。 注 意 sidecar 不 涉及 到 容器 间 的 流量 ， 因 为 它们 都 在 同一 个 pod 中 。 


手动 注入 sidecar 

istioctl 命令 行 中 有 一 个 称 为 kube-inject 的 便利 工具 ， 使 用 它 可 以 将 |stio 的 
sidecar 规范 添加 到 kubernetes 工作 负载 的 规范 配置 中 。 与 Initializer 程序 不 

F] > kube-inject 只 是 将 YAML 规范 转换 成 包含 Istio sidecar 的 规范 。 您 需要 使 


用 标准 的 工具 如 kubectl 来 部 署 修改 后 的 YAML。 例 如 ， 以 下 命令 将 sidecar 添 
加 到 sleep.yaml 文件 中 指定 的 pod 中 ， 并 将 修改 后 的 规范 提交 给 kubernetes : 


kubectl apply -f <(istioctl kube-inject -f samples/sleep/sleep.y 
aml) 


示例 
我 们 来 试 一 试 将 lstio sidecar 注入 到 sleep 服务 中 去 。 


kubectl apply -f <(istioctl kube-inject -f samples/sleep/sleep.y 
aml) 


Kube-inject 子 命令 将 Istio sidecar 和 init 容器 注入 到 deployment 配置 中 ， 转 换 后 
的 输出 如 下 所 示 : 


略 过 
apiVersion: extensions/vibeta1 
kind: Deployment 
metadata: 
annotations: 
sidecar.istio.io/status: injected-version-root@69916ebba0fc- 
0.2.6-081ffece00c82cb9de33cd5617682999aee5298d 
name: sleep 
spec: 
replicas: 1 
template: 
metadata: 
annotations: 
sidecar.istio.io/status: injected-version-root@69916ebba 
Ofc-0.2.6-081ffece00c82cb9de33cd5617682999aee5298d 
labels: 
app: sleep 
spec: 
containers: 
- name: sleep 
image: tutum/curl 
command: ["/bin/sleep","infinity"] 
imagePullPolicy: IfNotPresent 
- name: istio-proxy 
image: docker.io/istio/proxy debug:0.2.6 
args: 
略 过 
initContainers: 
- name: istio-init 
image: docker.io/istio/proxy init:0.2.6 
imagePullPolicy: IfNotPresent 
args: 
略 过 


注入 sidecar 的 关键 在 于 initContainers 和 istio-proxy 容器 。 为 了 简洁 起 见 ， 
上 述 输出 有 所 省 略 。 


验证 sleep deployment ¥ & 4 sidecar ° injected-version 对 应 于 注入 的 sidecar 镜 
像 的 版 本 和 镜像 的 TAG 。 在 您 的 设置 的 可 能 会 有 所 不 同 。 


echo $(kubectl get deployment sleep -o jsonpath='{.metadata.anno 
tations.sidecar\.istio\.io\/status}' ) 


injected-version-9c7c291eab0a522f8033decdOf5b031f5ed0e126 


你 可 以 查看 包含 注入 的 容器 和 挂 载 的 volume 的 完整 deployment 信息 。 


kubectl get deployment sleep -0 yaml 


自动 注入 sidecar 


Istio sidecar 可 以 在 部 署 之 前 使 用 Kubernetes 中 一 个 名 为 Initializer 的 Alpha 功能 
自动 注入 到 Pod 中 。 


注意 : Kubernetes InitializerConfiguration 没 有 命名 空间 ， 适 用 于 整个 集群 的 工 
作 负 载 。 不 要 在 共享 测试 环境 中 启用 此 功能 。 


前 置 条 件 


Initializer 需要 在 集群 设置 期 间 显 示 启 用 ， 如 此 处 所 述 。 假 设 集群 中 已 启用 
RBAC， 则 可 以 在 不 同 环境 中 启用 初始 化 程序 ， 如 下 所 示 : 


e GKE 


gcloud container clusters create NAME \ 
--enable-kubernetes-alpha \ 
--machine-type-ni-standard-2 \ 
--num-nodes=4 \ 
--no-enable-legacy-authorization \ 
- -Zone=ZONE 


e IBM Bluemix kubernetes v1.7.4 或 更 高 版 本 的 集群 已 默认 启用 initializer 。 
e Minikube 


Minikube v0.22.1 或 更 高 版 本 需要 为 GenericAdmissionWebhook 功能 配置 适 
当 的 证 书 。 获 取 最 新 版 本 : https://github.com/kubernetes/minikube/releases. 


minikube start \ 
--extra-config-apiserver.Admission.PluginNames-"Initiali 

zers, NamespaceLifecycle, LimitRanger, ServiceAccount, DefaultSt 

orageClass,GenericAdmissionWebhook,ResourceQuota" \ 
--kubernetes-version=v1.7.5 


Lr 
dC X 
您 现在 可 以 从 Istio 安装 根 目 录 设 置 |stio Initializer ° 


kubectl apply -f install/kubernetes/istio-initializer.yaml 


将 会 创建 下 列 资源 : 


1. istio-sidecar InitializerConfiguration 资源 ， 指 定 Istio sidecar 注入 的 资 
源 。 默 认 情 况 下 lstio sidecar 将 被 注入 到 deployment ^ statefulset ^ 

job 和 daemonset 中 。 

2. istio-inject ConfigMap，initializer 的 默认 注入 策略 ， 一 组 初始 化 
namespace， 以 及 注入 时 使 用 的 模版 参数 。 这 些 配置 的 详细 说 明 请 参考 配置 
选项 。 

3. istio-initializer Deployment， 运 行 initializer 控制 器 。 

4. istio-initializer-service-account ServiceAccount* M f istio- 
initializer deployment’ ClusterRole 和 ClusterRoleBinding 在 

install/kubernetes/istio.yaml 中 定义 。 注 意 所 有 的 资源 类 型 都 需要 有 
initialize 和 patch 。 正 式 处 于 这 个 原因 ，initializer 要 作为 
deployment 的 一 部 分 来 运行 而 不 是 诬 入 到 其 它 控制 器 中 ， 例 如 istio-pilot 。 


验证 


为 了 验证 sidecar LF RAZA > A EH sleep 服务 创建 deployment 和 
service ° 


kubectl apply -f samples/sleep/sleep.yaml 


验证 sleep deployment ¥ & 4 sidecar ° injected-version 对 应 于 注入 的 sidecar 4& 
像 的 版 本 和 镜像 的 TAG。 在 您 的 设置 的 可 能 会 有 所 不 同 。 


$ echo $(kubectl get deployment sleep -o jsonpath='{.metadata.an 
notations.sidecar\.istio\.io\/status}') 


injected-version-9c7c291eab0a522f8033decdOf5b031f5ed0e126 


你 可 以 查看 包含 注入 的 容器 和 挂 载 的 volume 的 完整 deployment 信息 。 


kubectl get deployment sleep -0 yaml 


了 解 发 生 了 什么 
以 下 是 将 工作 负载 提交 给 Kubernetes 后 发 生 的 情况 : 


1) kubernetes 将 sidecar.initializer.istio.io 添加 到 工作 负载 的 pending 
initializer 列表 中 。 


2) istio-initializer 控制 器 观察 到 有 一 个 新 的 未 初始 化 的 工作 负载 被 创建 了 。pending 
initializer 列表 中 的 第 一 个 个 将 作为 sidecar.initializer.istio.io 的 名 称 。 


3) istio-initializer 检查 它 是 否 负责 初始 化 namespace 中 的 工作 负载 。 如 果 没 有 为 该 
namespace 配置 initializer， 则 不 需要 做 进一步 的 工作 ， 而 且 initializer 会 忽略 工作 
负载 。 默 认 情 况 下 ，initializer 负责 所 有 的 namespace (参考 配置 选项 ) o 


4) istio-initializer 将 自己 从 pending initializer 中 移 除 。 如 果 pending initializer 列表 
3E € » M] Kubernetes 不 回 结 来 工作 负载 的 创建 。 错 误 配 置 的 initializer 意味 着 破损 
的 集群 。 

5) istio-initializer 检查 mesh 的 默认 注入 策略 ， 并 检查 所 有 单个 工作 负载 的 策略 负 


载 值 ， 以 确定 是 否 需 要 注入 sidecar 。 


6) istio-initializer 向 工作 负载 中 注入 sidecar 模板 ， 然 后 通过 PATCH 向 kubernetes 


一 一 


提交 。 


7) kubernetes 正常 的 完成 了 工作 负载 的 创建 ， 并 且 工 作 负 载 中 已 经 包含 了 注入 的 
sidecar ° 


配置 选项 


istio-initializer 具有 用 于 注入 的 全 局 默认 策略 以 及 每 个 工作 负载 覆盖 配置 。 全 局 策略 
由 istio-inject ConfigMap 配置 (请 参见 下 面 的 示例 ) © Initializer pod 必须 重 
新 启动 以 采用 新 的 配置 更 改 。 


apiVersion: v1 
kind: ConfigMap 
metadata: 
name: istio-inject 
namespace: istio-system 
data: 
config: |- 
policy: "enabled" 
namespaces: [""] # everything, aka v1.NamepsaceAll, aka clus 
ter-wide 


# excludeNamespaces: ["ns1i", "ns2"] 
initializerName: "sidecar.initializer.istio.io" 
params: 


initImage: docker.io/istio/proxy init:0.2.6 
proxyImage: docker.io/istio/proxy:0.2.6 
verbosity: 2 

version: 0.2.6 

meshConfigMapName: istio 

imagePullPolicy: IfNotPresent 


下 面 是 配置 中 的 关键 参数 : 
1. policy 


off -禁用 initializer 修改 资源 。pending 的 
sidecar.initializer.istio.io initializer 将 被 删除 以 避免 创建 阻塞 资 
disable - initializer 不 会 注入 sidecar 到 watch 的 所 有 namespace 的 资源 
中 。 启 用 sidecar 注入 请 将 sidecar.istio.io/inject 注解 的 值 设 置 为 


true ° 


enable - initializer 将 会 注入 sidecar 到 watch 的 所 有 namespace 的 资源 
T » XH sidecar 注入 请 将 sidecar.istio.io/inject 注解 的 值 设置 为 


false ° 
2. Namespaces 


要 watch 和 初始 化 的 namespace 列表 。 特 殊 的 "" namespace 对 应 于 
vi.NamespaceAll 并 配置 初始 化 程序 以 初始 化 所 有 namespace。 kube- 
system 、 kube-publice 和 istio-system 被 免除 初始 化 。 


1. excludeNamespaces 


从 Istio initializer 中 排除 的 namespace 列表 。 不 可 以 定义 为 
vi.NamespaceAll 或 者 与 namespaces 一 起 定义 。 


. initializerName 


这 必须 与 InitializerConfiguration 中 initializer 3x € 55 49 Z #6 48 Æ Ae » Initializer 
只 处 理 匹 配 其 配置 名 称 的 工作 负载 。 


. params 


这 些 参数 允许 您 对 注入 的 sidecar 进行 有 限 的 更 改 。 更 改 这 些 值 不 会 影响 已 部 


署 的 工作 负载 。 


重 写 自动 注入 


单个 工作 负载 可 以 通过 使 用 sidecar.istio.io/inject 注解 重 写 全 局 策略 。 


果 注 解 被 省 略 ， 则 使 用 全 局 策略 。 


如 果 注 解 的 值 是 true ， 则 不 管 全 局 策略 如 何 ，sidecar 都 将 被 注入 。 


如 果 注 解 的 值 是 false ， 则 不 管 全 局 策略 如 何 ，sidecar 都 不 会 被 注入 。 


下 表 显 示 全 局 策略 和 每 个 工作 负载 覆盖 的 组 合 。 
policy workload annotation injected 
off N/A no 
disabled omitted no 
disabled false no 
disabled true yes 
enabled omitted yes 
enabled false no 
enabled true yes 


例如 ， 即 使 全 局 策 


Wt disable 


> 下 面 的 deployment 也 会 被 注入 sidecar。 


如 


apiVersion: extensions/vibeta1 
kind: Deployment 
metadata: 

name: myapp 

annotations: 

sidecar.istio.io/inject: "true" 

spec: 

replicas: 1 

template: 


这 是 在 包含 |stio fe 3E Istio 服务 的 混合 群集 中 使 用 自动 注入 的 好 方法 。 
5p s, Initializer 
运行 下 面 的 命令 ， 删 除 |stio initializer : 


kubectl delete -f install/kubernetes/istio-initializer.yaml 


注意 上 述 命令 并 不 会 删除 已 注入 到 Pod 中 的 sidecar。 要 想 删 除 这 些 sidecar» $ € 
在 不 使 用 initializer 的 情况 下 重新 部 署 这 些 pod 。 


拓展 Istio Mesh 


将 虚拟 机 或 裸 机 集成 到 部 署 在 kubernetes 集群 上 的 Istio mesh 中 的 说 明 » 


前 置 条 件 
e 按照 安装 指南 在 kubernetes 集群 上 安装 Istio service mesh » 


e 机 器 必须 具有 到 mesh 端点 的 IP 地 址 连接 。 这 通常 需要 一 个 VPC 或 者 
VPN， 以 及 一 个 向 端点 提供 直接 路 由 (没有 NAT 或 者 防火 墙 拒绝 ) 的 容器 
络 。 及 其 不 需要 访问 有 Kubernetes 分 配 的 cluster IP ° 


e 虚拟 机 必须 可 以 访问 到 Istio 控制 平面 服务 (如 Pilot、Mixer、CA) 和 
Kubernetes DNS 服务 器 。 通 常 使 用 内 部 负载 均衡 器 来 实现 。 


您 也 可 以 使 用 NodePort， 在 虚拟 机 上 运行 |stio 的 组 件 ， 或 者 使 用 自 定义 网 络 
置 ， 有 几 个 单独 的 文档 会 涵盖 这 些 高 级 配置 。 


安装 过 程 包括 准备 用 于 拓展 的 mesh 和 安装 和 配置 虚拟 机 。 


install/tools/setupMeshEx.sh : 这 是 一 个 帮助 大 家 设置 kubernetes 环境 的 示例 脚 
本 。 检 查 脚 本 内 容 和 支持 的 环境 变量 (如 GCP_OPTS) ° 


install/tools/setuplstioVM.sh : 这 是 一 个 用 于 配置 主机 环境 的 示例 脚本 。 您 应 该 根 
据 您 的 配置 工具 和 DNS 要 求 对 其 进行 自 定 义 。 


准备 要 拓展 的 Kubernetes 集群 : 


e 为 Kube DNS、Pilot、Mixer 和 CA 安装 内 部 负载 均衡 器 (ILB) 。 每 个 云 供应 
商 的 配置 都 有 所 不 同 ， 根 据 具 体 情况 修改 注解 。 


0.2.7 版 本 的 YAML 文件 的 DNS ILB 的 namespace 配置 不 正确 。 使 用 这 一 个 
替代 。 setupMeshEx.sh 中 也 有 错误 。 使 用 上 面 链 接 中 的 最 新 文件 或 者 从 
GitHub.com/istio/istio 克隆 。 


kubectl apply -f install/kubernetes/mesh-expansion.yaml 


e 生成 要 部 署 到 虚拟 机 上 的 Istio cluster.env 配置 。 该 文件 中 包含 要 拦截 的 
cluster IP 地 址 范围 。 


export GCP_OPTS="--zone MY ZONE --project MY PROJECT" 

install/tools/setupMeshEx.sh generateClusterEnv MY CLUSTER NAME 
该 示例 生成 的 文件 : 

cat cluster.env 


ISTIO_SERVICE_CIDR=10.63.240.0/20 


e 产生 虚拟 机 使 用 的 DNS 配置 文件 。 这 样 可 以 让 虚拟 机 上 的 应 用 程序 解析 到 集 
群 中 的 服务 名 称 ， 这 些 名 称 将 被 sidecar 拦截 和 转发 。 


# Make sure your kubectl context is set to your cluster 
install/tools/setupMeshEx.sh generateDnsmasq 


该 示例 生成 的 文件 : 


cat kubedns 


server-/svc.cluster.local/10.150.0.7 
address-/istio-mixer/10.150.0.8 
address-/istio-pilot/10.150.0.6 
address-/istio-ca/10.150.0.9 
address-/istio-mixer.istio-system/10.150.0.8 
address-/istio-pilot.istio-system/10.150.0.6 
address-/istio-ca.istio-system/10.150.0.9 


bz 


TX B uS 
例如 ， 您 可 以 使 用 下 面 的 “一 条 龙 " 脚 本 复制 和 安装 配置 : 


# 检查 该 脚本 看 看 它 是 否 满 足 您 的 需求 

# 在 Mac 上， 使 用 brew install base64 或 者 set BASE64_DECODE="/usr 
/bin/base64 -D" 

export GCP_OPTS="--zone MY_ZONE --project MY_PROJECT" 


install/tools/setupMeshEx.sh machineSetup VM_NAME 


e. 将 配置 文件 和 Istio 的 Debian 文件 复制 到 要 加 入 到 集群 的 每 台 机 器 上 。 重 命名 
为 /etc/dnsmasq.d/kubedns 
和 /var/lib/istio/envoy/cluster.env ° 
e 配置 和 验证 DNS 配置 。 需 要 安装 dnsmasq 或 者 直接 将 其 添加 到 
/etc/resolv.conf 中 ， 或 者 通过 DHCP 脚本 。 验 证 配置 是 否 有 效 ， 检 查 虚 
拟 机 是 否 可 以 解析 和 连接 到 pilot， 例如: 


在 虚拟 机 或 外 部 主机 上 : 


host istio-pilot.istio-system 


产生 的 消息 示例 : 


# Verify you get the same address as shown as "EXTERNAL-IP" in ' 
kubectl get svc -n istio-system istio-pilot-ilb' 
istio-pilot.istio-system has address 10.150.0.6 


检查 是 否 可 以 解析 cluster IP。 实 际 地 址 取决 您 的 deployment : 
host istio-pilot.istio-system.svc.cluster.local. 
该 示例 产生 的 消息 : 


istio-pilot.istio-system.svc.cluster.local has address 10.63.247 
. 248 


同样 检查 istio-ingress : 
host istio-ingress.istio-system.svc.cluster.local. 
该 示例 产生 的 消息 : 


istio-ingress.istio-system.svc.cluster.local has address 10.63.2 
43.30 


e 验证 连接 性 ， 检 查 迅 即 是 否 可 以 连接 到 Pilot 的 端点 : 


curl 'http://istio-pilot.istio-system:8080/v1/registration/istio 
-pilot.istio-system.svc.cluster.local|http-discovery' 


"hosts": [ 


"lp-address": "10.60.1.4", 
"port": 8080 


} 
] 


A 在 虚拟 机 上 使 用 上 面 的 地 址 。 将 直接 连接 到 运行 istio-pilot 的 pod» 
curl 'http://10.60.1.4:8080/v1/registration/istio-pilot.istio-sy 
stem.svc.cluster.local|http-discovery' 


e 提取 出 实话 Istio ATE secret 并 将 它 复制 到 机 器 上 。lstio 的 默认 安装 中 包括 
CA， 即 使 是 禁用 了 自动 mTLS 设置 (她 为 每 个 service account 创建 
secret * secret 命名 为 istio.«serviceaccount» ) 也 会 生成 |stio secret ° 
建议 您 执行 此 步骤 ， 以 便 日 后 启用 mTLS， 并 升级 到 默认 局 用 mTLS 的 未 来 版 
本 。 


# ACCOUNT 默认 是 'default' > SERVICE ACCOUNT 是 环境 变量 

# NAMESPACE 默认 为 当前 namespace SERVICE NAMESPACE 是 环境 变量 

# (这 一 步 由 machineSetup 完成 ) 

# 在 Mac 上 执行 brew install base64 或 者 set BASE64_DECODE="/usr/b 
in/base64 -D" 

install/tools/setupMeshEx.sh machineCerts ACCOUNT NAMESPACE 


生成 的 文件 ( key.pem , root-cert.pem , cert-chain.pem ) 必须 拷贝 到 每 
台 主 机 的 /etc/certs 目录 ， 并 且 让 istio-proxy 可 读 。 


e 安装 lstio Debian 文件 ， 启 动 istio 和 istio-auth-node-agent 服务 。 
从 github releases 获取 Debian 安装 包 : 


A 


# 注意 : 在 软件 源 配置 好 后 ， 下 面 的 额 命令 可 以 使 用 'apt-get' 命令 替代 


source istio.VERSION # defines version and URLS env var 

curl -L ${PILOT_DEBIAN_URL}/istio-agent.deb > ${ISTIO_STAGIN 
G}/istio-agent.deb 

curl -L ${AUTH_DEBIAN_URL}/istio-auth-node-agent.deb > ${IST 
IO STAGINGj;/istio-auth-node-agent.deb 

curl -L $[PROXY DEBIAN URL)/istio-proxy.deb > $(ISTIO STAGIN 
G}/istio-proxy.deb 


dpkg -i istio-proxy-envoy.deb 
dpkg -i istio-agent.deb 
dpkg -i istio-auth-node-agent.deb 


systemctl start istio 
systemctl start istio-auth-node-agent 


------ 手动 安装 步骤 结束 ------ 
安装 完成 后 ， 机 器 就 能 访问 运行 在 Kubernetes 集群 上 的 服务 或 者 其 他 的 mesh 4 


# 假设 您 在 'bookinfo' namespace 下 安装 的 bookinfo 
curl productpage.bookinfo.svc.cluster.local:9080 


html content 


检查 进程 是 否 正在 运行 : 


ps aux |grep istio 


root 6941 0.0 0.2 75392 16820 ? Ssl 21:32 0:00 
/usr/local/istio/bin/node_agent --logtostderr 
root 6955 0.0 0.0 49344 3048 ? Ss 21:32 0:00 


su -s /bin/bash -c INSTANCE IP-10.150.0.5 POD NAME-demo-vm-1 POD 
_NAMESPACE=default exec /usr/local/bin/pilot-agent proxy > /var/ 
log/istio/istio.log istio-proxy 


istio-p+ 7016 0.0 0.1 215172 12096 ? Ssl 21:32 0:00 
/usr/local/bin/pilot-agent proxy 
istio-p+ 7094 4.0 0.3 69540 24800 ? Sl 21:32 0:37 


/usr/local/bin/envoy -c /etc/istio/proxy/envoy-revi.json --rest 
art-epoch 1 --drain-time-s 2 --parent-shutdown-time-s 3 --servic 
e-cluster istio-proxy --service-node sidecar~10.150.0.5~demo-vm- 
1.default-default.svc.cluster.local 


ls Er H—————Ó————— ÁO À—!] 


检查 lstio auth-node-agent 是 否 健康 : 


sudo systemctl status istio-auth-node-agent 


e istio-auth-node-agent.service - istio-auth-node-agent: The Ist 
io auth node agent 

Loaded: loaded (/lib/systemd/system/istio-auth-node-agent.ser 
vice; disabled; vendor preset: enabled) 

Active: active (running) since Fri 2017-10-13 21:32:29 UTC; 9 


s ago 
Docs: http://istio.io/ 
Main PID: 6941 (node agent) 
Tasks: 5 
Memory: 5.9M 
CPU: 92ms 
CGroup: /system.slice/istio-auth-node-agent.service 
L-6941 /usr/local/istio/bin/node agent --logtostderr 
Oct 13 21:32:29 demo-vm-1 systemd[1]: Started istio-auth-node-ag 
ent: The Istio auth node agent. 
Oct 13 21:32:29 demo-vm-1 node agent[6941]: I1013 21:32:29.46931 
4 6941 main.go:66] Starting Node Agent 
Oct 13 21:32:29 demo-vm-1 node agent[6941]: I1013 21:32:29.46936 
5 6941 nodeagent.go:96] Node Agent starts successfully. 
Oct 13 21:32:29 demo-vm-1 node agent[6941]: I1013 21:32:29.48332 
4 6941 nodeagent.go:112] Sending CSR (retrial #0) 
Oct 13 21:32:29 demo-vm-1 node agent[6941]: I1013 21:32:29.86257 
5 6941 nodeagent.go:128] CSR is approved successfully. Will r 
enew cert in 29m59.137732603s 


在 拓展 的 mesh 中 的 机 器 上 运行 服务 


e 配置 sidecar 拦截 端口 。 在 /var/lib/istio/envoy/sidecar.env 中 通过 
ISTIO INBOUND PORTS 环境 变量 配置 。 


例如 (运行 服务 的 虚拟 机 ) 


echo "ISTIO_INBOUND_PORTS=27017, 3306, 8080" > /var/lib/istio 
/envoy/sidecar.env 
systemctl restart istio 


e 手动 配置 selector-less 的 service 和 endpoint » "selector-less" service 用 于 那 
些 不 依托 Kubernetes pod 的 service。 


例如 ， 在 有 权限 的 机 器 上 修改 Kubernetes 中 的 service : 


# istioctl register servicename machine-ip portname: port 
istioctl -n onprem register mysql 1.2.3.4 3306 
istioctl -n onprem register svc1 1.2.3.4 http: 7000 


安装 完成 后 ，Kubernetes pod 和 其 它 mesh 扩展 将 能 够 访问 集群 上 运行 的 服务 。 


请 参阅 拓展 Booklnfo Mesh 指南 。 


28 & bookinfo 示例 应 用 

该 示例 部 署 由 四 个 单独 的 微服 务 组 成 的 简单 应 用 程序 ， 用 于 演示 lstio 服 务 网 格 的 各 
种 功能 。 

概况 


在 本 示例 中 ， 我 们 将 部 署 一 个 简单 的 应 用 程序 ， 显 示 书 籍 的 信息 ， 类 似 于 网 上 书店 
的 书籍 条 目 。 在 页 面 上 有 书籍 的 描述 、 详 细 信息 (ISBN、 页 数 等 ) 和 书评 。 
Booklnfo 应 用 程序 包括 四 个 独立 的 微服 务 : 


e productpage : productpage( 产 品 页 面 ) 微 服务 ， 调 用 details 和 reviews 微服 务 


来 填充 页 面 。 
e details : details 微服 务 包 含 书籍 的 详细 信息 。 
e reviews : reviews 微服 务 包含 书籍 的 点 评 。 它 也 调用 gs 微服 务 。 
e ratings : ratings 微服 务 包含 随 书 评 一 起 出 现 的 评分 信息 


有 3 个 版 本 的 reviews 微服 务 : 


e 版 本 v1 不 调用 ratings 服务 。 
e 版 本 V2 调用 ratings ， 并 将 每 个 评级 显示 为 1 到 5 个 黑色 星 。 
e 版 本 v3 调 用 ratings ， 并 将 每 个 评级 显示 为 1 到 5 个 红色 星 。 


应 用 程序 的 端 到 端 架构 如 下 所 示 。 


A 


Reviews-v1 


Requests 





图 片 - Booklnfo 


该 应 用 程序 是 多 语言 构建 的 ， 即 这 些微 服务 是 用 不 同 的 语言 编写 的 。 值 得 注意 的 
是 ， 这 些 服务 与 lstio 没有 任何 依赖 关系 ， 单 这 是 个 有 趣 的 Service Mesh 示例 ， 特 
别 是 因为 评论 服务 和 众多 的 语言 和 版 本 。 


开始 之 前 


如 果 您 还 没有 这 样 做 ， 请 按照 与 您 的 平台 安装 指南 对 应 的 说 明 安 装 lstio。 


部 署 应 用 程序 


使 用 lstio 运行 应 用 程序 示例 不 需要 修改 应 用 程序 本 身 。 相 反 ， 我 们 只 需要 在 支持 
Istio 的 环境 中 配置 和 运行 服务 ， Envoy sidecar 将 会 注入 到 每 个 服务 中 。 所 需 的 命 
令 和 配置 根据 运行 时 环境 的 不 同 而 有 所 不 同 ， 但 在 所 有 情况 下 ， 生 成 的 部 署 将 如 下 
所 示 : 


I 


Reviews-v1| | : 









€: python 


Requests 


图 片 - Booklnfo 


所 有 的 微服 务 都 将 与 一 个 Envoy sidecar 一 起 打包 ， 拦 截 这 些 服务 的 入 站 和 出 站 的 
调用 请 求 ， 提 供 通过 lstio 控制 平面 从 外 部 控制 整个 应 用 的 路 由 ， 膛 测 收集 和 策略 执 
行 所 需 的 hook。 


要 启动 该 应 用 程序 ， 请 按照 以 下 对 应 于 您 的 lstio 运行 时 环境 的 说 明 进行 操作 。 


在 Kubernetes ¥ 24 


注意 : 如 果 您 使 用 GKE， 清 确保 您 的 集群 至 少 有 4 个 标准 的 GKE 节点 。 如 果 
您 使 用 Minikube， 请 确保 您 至 少 有 4GB AG © 


1. 将 目录 更 改 为 lstio 安装 目录 的 根 目 录 。 
2. 构建 应 用 程序 容器 : 
如 果 您 使 用 自动 注入 sidecar 的 方式 部 署 的 集群 ， 那 么 只 需要 使 用 


kubectl 命令 部 署 服务 : 


kubectl apply -f samples/bookinfo/kube/bookinfo.yaml 


如 果 您 使 用 手动 注入 sidecar 的 方式 部 署 的 集群 ， 清 使 用 下 面 的 命令 : 


kubectl apply -f <(istioctl kube-inject -f samples/apps/book 
info/bookinfo.yaml) 


请 注意 ， 该 istioctl kube-inject 命令 用 于 在 创建 部 署 之 前 修改 
bookinfo.yaml 文件 。 这 将 把 Envoy 注入 到 Kubernetes 资源 。 


上 述 命令 启动 四 个 微服 务 并 创建 网 关 入 口 资源 ， 如 下 图 所 示 。3 个 版 本 的 评论 
的 服务 v1、v2、vV3 都 已 启动 。 


请 注意 在 实际 部 署 中 ， 随 着 时 间 的 推移 部 署 新 版 本 的 微服 务 ， 而 不 是 同时 
部 署 所 有 版 本 。 


3. 确认 所 有 服务 和 pod 已 正确 定义 并 运行 


kubectl get services 


这 将 产生 以 下 输出 : 


NAME CLUSTER-IP EXTERNAL - IP PORT(S) 


AGE 
details 10.0.0.31 «none» 9080/T 
CP em 
istio-ingress 10.0.0.122 «pending» 80:315 
65/TCP 8m 
istio-pilot 10.0.0.189 <none> 8080/T 
CP am 
istio-mixer 10.0.0.132 «none» 9091/T 
CP, 42422/TCP 8m 
kubernetes 10.0.0.1 <none> 443/TC 
P 14d 
productpage 10.0.0.120 <none> 9080/T 
CP 6m 
ratings 10.0.0.15 <none> 9080/T 
CP 6m 
reviews 10.0.0.170 <none> 9080/T 
CP 6m 

aj 


而 且 


kubectl get pods 


将 产生 : 

NAME READY STATUS 
RESTARTS AGE 

details-v1-1520924117-48z17 2/2 Runnin 

g 0 6m 

istio-ingress-3181829929-xrrk5 1/1 Runnin 

g 0 8m 

istio-pilot -175173354-d6jm7 2/2 Runnin 

g 0 8m 

istio-mixer -3883863574-jt09j 2/2 Runnin 

g 0 8m 

productpage -v1-560495357 - jk11z 2/2 Runnin 

g 0 6m 

ratings-v1i-734492171-rnr51 2/2 Runnin 

g 0 6m 

reviews -v1-874083890 - FOqfO 2/2 Runnin 

g 0 6m 

reviews -v2-1343845940-b34q5 2/2 Runnin 

g 0 6m 

reviews -v3-1813607990-8ch52 2/2 Runnin 


g 0 6m 


确定 ingress IP 和 端口 


1. 如 果 您 的 kubernetes 集群 环境 支持 外 部 负载 均衡 器 的 话 ， 可 以 使 用 下 面 的 命 


2. 


3. 


4 ik JR. ingress 的 I|P 地 址 : 


kubectl get ingress -o wide 


输出 如 下 所 示 : 
NAME HOSTS ADDRESS PORTS 
gateway * 130.211.10.121 80 


Ingress 服务 的 地 址 是 : 


export GATEWAY URL-130.211.10.121:80 


AGE 
1d 


GKE : 如 果 服 务 无 法 获取 外 部 IP > kubectl get ingress -o wide 会 显示 
工作 节点 的 列表 。 在 这 种 情况 下 ， 您 可 以 使 用 任何 地 址 以 及 NodePort 访问 入 
口 。 但 是 ， 如 果 集 群 具有 防火 墙 ， 则 还 需要 创建 防火 墙 规 则 以 允许 TCP 流 量 到 


NodePort， 您 可 以 使 用 以 下 命令 创建 防火 墙 规 则 : 


export GATEWAY_URL=<workerNodeAddress>:$(kubectl get svc ist 
io-ingress -n istio-system -o jsonpath='{.spec.ports[0].node 


Port)') 


gcloud compute firewall-rules create allow-book --allow tcp: 
$(kubectl get svc istio-ingress -n istio-system -o jsonpath- 


'{.spec.ports[0].nodePort}') 


IBM Bluemix Free Tier : 在 免费 版 的 Bluemix 的 kubernetes 集群 中 不 支持 外 
部 负载 均衡 器 。 您 可 以 使 用 工作 节点 的 公共 IP， 并 通过 NodePort 来 访问 


ingress。 工 作 节 点 的 公共 IP 可 以 通过 如 下 命令 获取 : 


bx cs workers <cluster-name or id> 


export GATEWAY_URL=<public IP of the worker node»:$(kubectl 
get svc istio-ingress -n istio-system -o jsonpath='{.spec.po 


rts[0].nodePort}' ) 


4. Minikube : Minikube 不 支持 外 部 负载 均衡 器 。 您 可 以 使 用 ingress 服务 的 主机 
IP 和 NodePort 来 访问 ingress : 


export GATEWAY URL-$(kubectl get po -1 istio-ingress -o 'jso 
npath={.items[0].status.hostIP}'):$(kubectl get svc istio-in 
gress -o 'jsonpath={.spec.ports[0].nodePort}' ) 


在 Consul X, Eureka 环境 下 使 用 Docker 运行 


1. 切换 到 lstio 的 安装 根 目 录 下 。 
2. 局 动 应 用 程序 容器 。 


i 执行 下 面 的 命令 测试 Consul : 


docker-compose -f samples/bookinfo/consul/bookinfo.yaml 
up -d 


.执行 下 面 的 命令 测试 Eureka : 


docker-compose -f samples/bookinfo/eureka/bookinfo.yaml 
up -d 


3. 确认 所 有 容器 都 在 运行 : 
docker ps -a 


如 果 Istio Pilot 容器 终止 了 ， 重 新 执行 上 面 的 命令 重新 运行 。 


4. 设置 GATEWAY_URL : 


export GATEWAY_URL=localhost:9081 


T-— 


使 用 以 下 curl 命令 确认 Booklnfo 应 用 程序 正在 运行 : 


curl -o /dev/null -s -w "%{http_code}\n" http://${GATEWAY_URL}/p 
roductpage 


200 


你 senis ae ld http://$GATEWAY URL/productpage 页 面 访问 
Bookinfo 网 页 。 如 果 您 多 次 刷新 浏览 器 将 在 productpage 中 看 到 评论 的 不 同 的 版 
本 ， ee round robin (2c ` € € ^ RAZZ) 的 方式 展现 ， 因 为 我 们 还 没 
有 使 用 Istio 来 控制 版 本 的 路 由 。 


现在 ， 您 可 以 使 用 此 示例 来 尝试 |stio 的 流量 路 由 、 故 障 注 入 、 速 率 限 制 等 功能 。 要 
继续 的 话 ， 请 参阅 |stio 指南 ， 具 体 取 决 于 您 的 兴趣 。 和 智能 路 由 是 初学 者 入 门 的 好 
清理 


在 完成 Booklnfo 示例 后 ， 您 可 以 纯 载 它 ， 如 下 所 示 : 
$r R, Kubernetes 环境 
删除 路 由 规则 ， 终 止 应 用 程序 pod 
samples/bookinfo/kube/cleanup.sh 
2. 确认 关闭 


istioctl get routerules #-- there should be no more routin 
g rules 

kubectl get pods #-- the BookInfo pods should be de 
leted 


卸载 docker 环境 
删除 路 由 规则 和 应 用 程序 容器 


i ZiM Consul 环境 安装 ， 执 行 下 面 的 命令 


samples/bookinfo/consul/cleanup.sh 


i. 若 使 用 Eureka 环境 安装 ， 执 行 下 面 的 命令 : 


samples/bookinfo/eureka/cleanup.sh 


2. 确认 清理 完成 : 


istioctl get routerules #-- there should be no more routin 
g rules 

docker ps -a #-- the BookInfo containers should 
be delete 
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作 rt, 4. 
集 成 , 虚 PA du 


集成 虚拟 机 


该 示例 跨越 Kubernetes 集群 和 一 组 虚拟 机 上 部 署 Bookinfo 服务 ， 描 述 如 何 使 用 
Istio service mesh 将 此 基础 架构 以 单一 mesh 的 方式 操控 。 


注意 : 本 文档 还 在 建设 中 ， 并 且 只 在 Google Cloud Platform 上 进行 过 测试 。 
在 IBM Bluemix 或 其 它 平台 上 ，pod 的 overlay 网 络 跟 虚拟 机 的 网 络 是 隔离 
的 。 即使 使 用 |stio， 虚 拟 机 也 不 能 直接 与 Kubernetes Pod 进 本 通信 


gu 
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开始 之 前 


e 按照 安装 指南 上 的 步骤 部 署 |stio。 
e 264 Bookinfo 示例 应 用 程序 (在 bookinfo namespace F) 。 
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e 在 |stio 集群 相同 的 项 目下 创建 名 为 vm-1 的 虚拟 机 ， 并 加 入 到 Mesh e 


在 虚拟 机 上 运行 mysql 


我 们 将 首先 在 虚拟 机 上 安装 mysql， 将 其 配置 成 评分 服务 的 后 台 存 储 。 


在 虚拟 机 上 执行 


sudo apt-get update && sudo apt-get install -y mariadb-server 
sudo myag 

A 授权 root A P ù 

GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' IDENTIFIED BY 
'password' WITH GRANT OPTION; 

quit; 

sudo systemctl restart mysql 


KF Mysql 的 详细 配置 请 见 : Mysql ° 


在 虚拟 机 上 执行 下 面 的 命令 ， 向 mysql 中 添加 评分 数据 库 。 


A 向 mysql 数据 库 中 添加 评分 数据 库 

curl -q https://raw.githubusercontent.com/istio/istio/master/sam 
ples/bookinfo/src/mysql/mysqldb-init.sql | mysql -u root -ppassw 
ord 


为 了 便于 直观 地 查看 bookinfo 应 用 程序 输出 的 差异 ， 可 以 更 改 使 用 以 下 命令 生成 的 
评分 


mysql -u root -ppassword test -e "select * from ratings;" 


tiara eae deditus + 
| ReviewID | Rating | 
Fe 站 二 + 
| 1 | 5 | 
| 2 | 4 | 
fo aaa ee 下 十 


# 修改 评分 
mysql -u root -ppassword test -e "update ratings set rating=1 
where reviewid=1;select * from ratings;" 


pasa aan ae Pacers nonus + 
| ReviewID | Rating | 
Pes epus Be mde + 
| 1 | 1 | 
| 2 | 4 | 
deed en P$eeessuse + 


找 出 将 添加 到 mesh 中 的 虚拟 机 的 IP 地 址 
在 虚拟 机 上 执行 : 


hostname -I 


将 mysql 服务 注册 到 mesh 中 


在 一 台 可 以 访问 istioctl 命令 的 主机 上 ， 注 册 该 虚拟 机 和 mysql db service : 


istioctl register -n vm mysqldb <ip-address-of-vm> 3306 

# 示例 输出 

$ istioctl register mysqldb 192.168.56.112 3306 

T1015 22:24:33.846492 15465 register.go:44] Registering for se 
rvice 'mysqldb' ip '192.168.56.112', ports list [{3306 mysql}] 
I1015 22:24:33.846550 15465 register.go:49] O labels ([]) and 

1 annotations ([alpha.istio.io/kubernetes-serviceaccounts-default 


] ) 
W1015 22:24:33.866410 15465 register.go:123] Got 'services "my 


sqldb" not found' looking up svc 'mysqldb' in namespace 'default' 
, attempting to create it 

W1015 22:24:33.904162 15465 register.go:139] Got 'endpoints "m 
ysqldb" not found' looking up endpoints for 'mysqldb' in namespa 
ce 'default', attempting to create them 

I1015 22:24:33.910707 15465 register.go:180] No pre existing e 
xact matching ports list found, created new subset {[{192.168.56 
.112 «nil» nilj] [] [{mysql 3306 }]} 

I1015 22:24:33.921195 15465 register.go:191] Successfully upda 
ted mysqldb, now with 1 endpoints 


]; 1| pas —'— E Si 
集群 管理 


如 果 你 之 前 在 kubernetes 上 运行 过 mysql， 您 需要 将 kubernetes 的 mysql service 
移 除 : 


kubectl delete service mysql 


执行 istioctl 来 配置 service (在 您 的 admin 机 器 上 ) 
istioctl register mysql IP mysql:PORT 
注意 : mysqldb 虚拟 机 不 需要 也 不 应 该 有 特别 的 kubernetes 权限 。 
使 用 mysql 服务 
bookinfo 中 的 评分 服务 将 使 用 机 器 上 的 数据 库 。 要 验证 它 是 否 有 效 ， 请 创建 使 用 虚 


拟 机 上 的 mysql db 的 评分 服务 的 v2 版 本 。 然 后 指定 强制 评论 服务 使 用 评分 v2 版 
本 的 路 由 规则 。 


L N 
7] 


# 创建 使 用 mysql 后 端的 评分 
istioctl kube-inject -n bookinfo -f samples/bookinfo/kube/bookin 
fo-ratings-v2-mysql-vm.yaml | kubectl apply -n bookinfo -f - 


# 强制 bookinfo 使 用 评分 后 端的 路 有 规则 
istioctl create -n bookinfo -f samples/bookinfo/kube/route-rule- 
ratings-mysql-vm.yaml 


您 可 以 验证 bookinfo 应 用 程序 的 输出 结果 ， 显 示 来 自 Reviewer 91 星 级 和 来 自 
Reviewer2 的 4 星 级 ， 或 者 更 改 虚 拟 机 上 的 评分 并 查看 结果 。 
同时 ， 您 还 可 以 在 RawVM MySQL 的 文档 中 找到 一 些 故障 排查 和 其 它 信息 。 
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Istio 中 sidecar 的 注入 及 示例 


我 们 知道 lstio 通过 L Pod 中 注入 一 个 sidecar 容器 来 将 Pod 纳入 到 Istio service 
mesh 中 的 ， 那 么 这 容器 的 注入 遵循 什么 ff 的 规范 ， 需 要 给 每 个 Pod +4 
加 哪些 配置 信息 才能 纳入 lstio service mesh 中 呢 ? 这 篇 文章 将 给 您 答案 。 


Pod Spec 中 需 满足 的 条 件 


为 了 成 为 Service Mesh 中 的 一 部 分 ，kubernetes 集群 中 的 每 个 Pod 都 必须 满足 如 
下 条 件 ， 这 些 规范 不 是 由 |stio 自动 注入 的 ， 而 需要 生成 kubernetes 应 用 部 署 的 
YAML 文件 时 需要 遵守 的 : 


1. 


Service 关联 : 每 个 pod 都 必须 只 属于 某 一 个 Kubernetes Service (当前 不 支 
持 一 个 pod 同时 属于 多 个 service) 。 
命名 的 端口 : Service 的 端口 必须 命名 。 端 口 的 名 字 必 须 遵循 如 下 格式 
<protocol>[-<suffix>] ， 可 以 是 http ^ http2 ^ grpc ^ 
mongo ^ X# redis 作为 «protocol» ， 这 样 才能 使 用 Istio 的 路 由 功 
能 。 例 如 name: http2-foo 和 name: http 都 是 有 效 的 端口 名 称 ， 而 
name: http2foo 不 是 。 如 果 端 口 的 名 称 是 不 可 识别 的 前 缓 或 者 未 命名 ， 那 
么 该 端口 上 的 流量 就 会 作为 普通 的 TCP 流量 来 处 理 〈 除 非 使 用 Protocol: 
UDP 明确 声明 使 用 UDP 端口 ) 。 


. 带 有 app label 的 Deployment : 我 们 建议 kubemetes 的 Deploymenet 资 


源 的 配置 文件 中 为 Pod 明确 指定 app label。 每 个 Deployment 的 配置 中 都 需 
要 有 个 与 其 他 Deployment 不 同 的 含有 意义 的 app labele app label 用 于 
在 分 布 式 追踪 中 添加 上 下 文 信息 。 


. Mesh 中 的 每 个 pod 里 都 有 一 个 Sidecar : 最 后 ，Mesh 中 的 每 个 pod 都 必须 


运行 与 |stio 兼容 的 sidecar。 以 下 部 分 介绍 了 将 sidecar 注入 到 pod 中 的 两 种 
方法 : 使 用 istioctl 命令 行 工 具 手 动 注入 ， 或 者 使 用 |stio Initializer 自动 注 
入 。 注 意 sidecar 不 涉及 到 流量 ， 因 为 它们 与 容器 位 于 同一 个 pod 中 。 


将 普通 应 用 添加 到 Istio service mesh 中 


lstio 官 方 的 示例 Bookinfo 中 并 没有 讲解 如 何 将 服务 集成 lstio， 只 给 出 了 YAML 配置 
文件 ， 而 其 中 需要 注意 哪些 地 方 都 没有 说 明 ， 假 如 我 们 自己 部 署 的 服务 如 何 使 用 
lstio 呢 ? 现在 我 们 有 如 下 两 个 普通 应 用 《代码 在 GitHub 上 ) ， 它 们 都 不 具备 微服 
务 的 高 级 特性 ， 比 如 限 流 和 熔断 等 ， 通 过 将 它们 部 署 到 kubernetes 并 使 用 Istio 来 
管理 : 


e k8s-app-monitor-test : 用 来 暴露 json 格式 的 metrics 
e k8s-app-monitor-agent : 访问 上 面 那个 应 用 暴露 的 metrics 并 生成 监控 图 


这 两 个 应 用 的 YAML 配置 如 下 ， 其 中 包含 了 lstio ingress 配置 ， 并 且 符 合 lstio 对 
Pod 的 spec 配置 所 指定 的 规范 。 


k8s-app-monitor-istio-all-in-one.yaml 文 件 


apiVersion: extensions/vibetal 
kind: Deployment 
metadata: 
annotations: 
kompose.cmd: kompose convert -f docker-compose. yaml 
kompose.version: 1.10.0 () 
creationTimestamp: null 
labels: 
app: k8s-app-monitor-agent 
name: k8s-app-monitor-agent 
spec: 
replicas: 1 
template: 
metadata: 
creationTimestamp: null 
labels: 
app: k8s-app-monitor-agent 
spec: 
containers: 
- env: 
- name: SERVICE NAME 
value: k8s-app-monitor-test 
image: jimmysong/k8s-app-monitor-agent:749f547 
name: monitor-agent 
ports: 
- containerPort: 8888 
restartPolicy: Always 
apiVersion: vi 
kind: Service 
metadata: 
annotations: 
kompose.cmd: kompose convert -f docker-compose.yaml 
kompose.version: 1.10.0 () 


creationTimestamp: null 
labels: 
app: k8s-app-monitor-agent 
name: k8s-app-monitor-agent 
spec: 
ports: 
- name: "http" 
port: 8888 
targetPort: 8888 
selector: 
app: k8s-app-monitor-agent 
apiVersion: extensions/vibeta1 
kind: Deployment 
metadata: 
annotations: 
kompose.cmd: kompose convert -f docker-compose.yaml 
kompose.version: 1.10.0 () 
creationTimestamp: null 
labels: 
app: k8s-app-monitor-test 
name: k8s-app-monitor-test 
spec: 
replicas: 1 
template: 
metadata: 
creationTimestamp: null 
labels: 
app: k8s-app-monitor-test 
spec: 
containers: 
- image: jimmysong/k8s-app-monitor-test:9c935dd 
name: monitor-test 
ports: 
- containerPort: 3000 
restartPolicy: Always 
apiVersion: vi 
kind: Service 
metadata: 
annotations: 
kompose.cmd: kompose convert -f docker-compose.yaml 
kompose.version: 1.10.0 () 
creationTimestamp: null 
labels: 
app: k8s-app-monitor-test 
name: k8s-app-monitor-test 


spec: 
ports: 
- name: "http" 
port: 3000 


targetPort: 3000 
selector: 


app: k8s-app-monitor-test 
ZZ Istio ingress 
apiVersion: extensions/vibetai 
kind: Ingress 


metadata: 
name: k8s-app-monitor-agent-ingress 
annotations: 
kubernetes.io/ingress.class: "istio" 
spec: 
rules: 
- http: 
paths: 
- path: /k8s-app-monitor-agent 
backend: 


serviceName: k8s-app-monitor-agent 
servicePort: 8888 


其 中 有 两 点 配置 需要 注意 。 


e Deployment 和 Service 中 的 label 名 字 必 须 包 含 app ，zipkin 中 的 
tracing 需要 使 用 到 这 个 标签 才能 追踪 

e Service 中 的 ports 配置 和 必须 包含 一 个 名 为 http 的 port， 这 样 在 
Istio ingress 中 才能 暴露 该 服务 


注意 : 该 YAML 文件 中 annotations 是 因为 我 们 一 开始 使 用 docker- 
compose 部 署 在 本 地 开发 测试 ， 后 来 再 使 用 kompose 将 其 转换 为 kubernetes 可 
识别 的 YAML 文件 。 

然后 执行 下 面 的 命令 就 可 以 基于 以 上 的 YAML 文件 注入 sidecar 配置 并 部 署 到 
kubernetes 集群 中 。 


kubectl apply -n default -f <(istioctl kube-inject -f manifests/ 
istio/k8s-app-monitor-istio-all-in-one.yaml) 


如 何在 本 地 启动 kubernetes 集群 进行 测试 可 以 参考 kubernetes-vagrant-centos- 
cluster 中 的 说 明 。 


Sidecar 注入 说 明 


手动 注入 需要 修改 控制 器 的 配置 文件 ， 如 deployment。 通 过 修改 deployment 文件 
中 的 pod 模板 规范 可 实现 该 deployment 下 创建 的 所 有 pod 都 注入 sidecar。 添 加 / 
更 新 /删除 sidecar 需要 修改 整个 deployment。 


自动 注入 会 在 pod 创建 的 时 候 注 入 sidecar， 无 需 更 改 控制 器 资源 。Sidecar 可 通过 
以 下 方式 更 新 : 


e 选择 性 地 手动 删除 pod 
e 系统 得 进行 deployment 滚动 更 新 


re 


手动 或 者 自动 注入 都 使 用 同样 的 模板 配置 。 自 动 注入 会 从 istio-system 命名 
间 下 获取 istio-inject 的 ConfigMap。 手 动 注入 可 以 通过 本 地 文件 或 者 
Configmap 。 


参考 


e Installing Istio Sidecar 
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如 何 参 与 Istio 社区 及 注意 事项 
本 文 讲述 了 如 何 参与 lstio 社区 和 进行 lstio 开发 时 需要 注意 的 事项 。 


工作 组 


绝 大 多 数 复杂 的 开源 项 目 都 是 以 工作 组 的 方式 组 织 的 ， 要 想 为 |stio 社区 做 贡献 可 以 
加 入 到 以 下 的 工作 组 (Working Group) 


e API Management 

e Config 

e Environments 

e Networking 

e Performance & Scalability 
e Policies & Telemetry 

e Security 

e Test & Release 


代码 规范 


Istio 的 代码 规范 沿用 CNCF 社区 的 代码 规范 。 


开发 指南 
进行 lstio 开发 之 前 需要 做 下 面 几 件 事情 : 


e 配置 基础 环境 ， 如 Kubernetes 
e 配置 代码 库 、 下 载 依 赖 和 测试 
e 配置 CircleC| 集成 环境 

e 编写 参考 文档 

e Git workflow 配置 


详 见 Dev Guide wiki ° 


设计 文档 


所 有 的 设计 文档 都 保存 在 Google Drive 中 ， 其 中 包括 以 下 资源 : 


e Technical Oversight Committee : ToC 管 理 的 文档 

e Misc : 一 些 杂 项 

e Working Groups : 最 重要 的 部 分 ， 各 个 工作 

e Presentations : Istio 相关 的 演讲 幻灯 片 ， 从 这 些 文稿 中 可 以 快速 了 解 |stio 
e Logo : Istio logo 

e Eng: 社区 相关 的 维护 文档 


社区 角色 划分 
根据 对 开发 者 和 要 求 和 贡献 程度 的 不 同 ，lstio 社区 中 包含 以 下 角色 : 


e Collaborator : 非 正 式 贡 献 者 ， 偶 尔 贡献 ， 任 何人 都 可 以 成 为 该 角色 
e Member: 正式 贡献 者 ， 经 常 贡献 ， 必 须 有 2 个 已 有 的 member 提名 
e Approver : 老手 ， 可 以 批准 member 的 贡献 

e Lead: 管理 功能 、 项 目 和 提议 ， 必 须 由 ToC 提名 

e Administrator : 管理 员 ， 管 理 和 控制 权限 ， 必 须 由 ToC 提名 

e Vendor : 贡献 |stio 项 目的 扩展 


详 见 lstio Community Roles ° 


各 种 功能 的 状态 


Istio 中 的 所 有 feature 根据 是 否 生产 可 用 、API 兼 容 性 、 性 能 、 维 护 策略 分 为 三 种 
AA: 


e Alpha: 仅仅 可 以 作为 demo ， 无 法 生产 上 使 用 ， 也 没有 性 能 保证 ， 随 时 都 可 能 
不 维护 

e Beta : 可 以 在 生产 上 使 用 了 ， 也 有 版 本 化 的 AP| 但 是 无 法 保证 性 能 ， 保 证 三 个 
月 的 维护 

e Stable : 可 以 上 生产 而 且 还 能 保证 性 能 ，API 向 后 兼容 ， 保 证 一 年 的 维护 


Istio 的 feature 分 为 四 大 类 : 


e 流量 管理 : 各 种 协议 的 支持 、 路 由 规则 配置 、Ingress TLS 等 
e 可 观察 性 : 监控 、 日 志 、 分 布 式 追踪 、 服 务 依赖 拓扑 

e 安全 性 : 各 种 checker 和 安全 性 配置 

e Core : 核心 功能 


功能 划分 与 各 种 功能 的 状态 详情 请 见 : https:;//istio.io/about/feature-stages.html 
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Istio 教程 


A3 X Istio 管理 Java 微服 务 的 案例 教程 ， 使 用 的 所 有 工具 和 软件 全 部 基于 开源 方 
案 ， 替 换 了 redhat-developer-demos/istio-tutorial 中 的 minishift 环境 ， 使 用 
kubernetes-vagrant-centos-cluster 替代 ， 沿 用 了 原 有 的 微服 务 示例 ， 使 用 Zipkin 
做 分 布 式 追踪 而 不 是 Jaeger。 


本 文中 的 代码 和 YAML 文件 见 https://github.com/rootsongjc/istio-tutorial ° 


准备 环境 
在 进行 本 教程 前 需要 先 准 备 以 下 工具 和 环境 。 


e 8G 以 上 内 存 

e Vagrant 2.0+ 

e Virtualbox 5.0 + 
e 提前 下 载 kubernetes1.9.1 的 release 压缩 包 
e docker 1.12+ 

e kubectl 1.9.1+ 
e maven 3.5.2+ 
e istioctl 0.7.1 

e git 

e Curl ` gzip ^ tar 
e kubetail 

e Siege 


安装 Kubernetes 


请 参考 kubernetes-vagrant-centos-cluster 在 本 地 启动 拥有 三 个 节点 的 kubernetes 
集群 。 


git clone https://github.com/rootsongjc/kubernetes-vagrant-cento 
s-cluster.git 

cd kubernetes-vagrant-centos-cluster 

vagrant up 


安装 Istio 


在 kubernetes-vagrant-centos-cluster 中 的 包含 |stio 0.7.1 的 安装 YAML 文件 ， 运 
行 下 面 的 命令 安装 Istio ° 


kubectl apply -f addon/istio/ 
运行 示例 


kubectl apply -n default -f <(istioctl kube-inject -f yaml/istio 
-bookinfo/bookinfo.yaml) 


在 您 自己 的 本 地 主机 的 /etc/hosts 文件 中 增加 如 下 配置 项 。 


172.17.8.102 grafana.istio.jimmysong.io 
172.17.8.102 servicegraph.istio.jimmysong.io 
172.17.8.102 zipkin.istio.jimmysong.io 


我 们 可 以 通过 下 面 的 URL 地 址 访问 以 上 的 服务 。 


Service URL 
grafana http://grafana.istio.jimmysong.io 
servicegraph http://servicegraph.istio.jimmysong.io/dotviz > http://servicegraph 


zipkin http://zipkin.istio.jimmysong.io 
详细 信息 请 参阅 https://istio.io/docs/guides/bookinfo.htm| 
部 署 示例 应 用 


在 打包 成 镜像 部 署 到 kubernetes 集群 上 运行 之 前 ， 我 们 先 在 本 地 运行 所 有 示例 。 


本 教程 中 三 个 服务 之 间 的 依赖 关系 如 下 : 


customer — preference — recommendation 


customer 和 preference 微服 务 是 基于 Spring Boot 构建 
的 ， recommendation 微服 务 是 基于 vert.x 构建 的 。 


customer 和 preference 微服 务 的 pom.xml 文件 中 都 引入 了 OpenTracing 
和 Jeager 的 依赖 。 


<dependency> 
<groupId>io.opentracing.contrib</groupId> 
<artifactId>opentracing-spring-cloud-starter</artifactId> 
<version>0.1.7</version> 

</dependency> 

<dependency> 
«groupId»com.uber.jaeger«/groupId» 
<artifactId>jaeger -tracerresolver</artifactId> 
<version>0.25.0</version> 

</dependency> 


本 地 运行 


我 们 首先 在 本 地 确定 所 有 的 微服 务 都 可 以 正常 运行 ， 然 后 再 打包 镜像 在 kubernetes 
集群 上 运行 。 


kz a) Jaeger 
使 用 docker #24 4T jagger ° 


docker run -d \ 
--rm \ 
-p5775:5775/udp \ 
-p6831:6831/udp \ 
-p6832:6832/udp \ 
-p16686:16686 \ 
-p14268:14268 \ 
jaegertracing/all-in-one:1.3 


Jaeger UI 地 址 http://localhost:16686 
Customer 


cd customer/java/springboot 
JAEGER_SERVICE_NAME=customer mvn \ 
spring-boot:run \ 
-Drun.arguments="--spring.config.location=src/main/resources/a 
pplication-local.properties" 


服务 访问 地 址 : http://localhost:8280 
Preference 


cd preference/java/springboot 
JAEGER_SERVICE_NAME=preference mvn \ 
spring-boot:run \ 
-Drun.arguments="--spring.config.location=src/main/resources/a 
pplication-local.properties" 


服务 访问 地 址 : http://localhost:8180 
Recommendation 


cd recommendation/java/vertx 
mvn vertx:run 


服务 访问 地 址 ; http://localhost:8080 


所 有 服务 都 启动 之 后 ， 此 时 访问 http://localhost:8280 将 会 看 到 如 下 输出 。 


customer => preference => recommendation vi from 'unknown': 1 
每 访问 一 次 最 后 的 数字 就 会 加 1。 


Jaeger 


此 时 访问 http://localhost:16686 将 看 到 Jaeger query Ul， 所 有 应 用 将 metrics 发 送 
到 Jeager 中 。 


可 以 在 Jaeger Ul 中 搜索 customer 和 preference service 的 trace 并 查看 每 
次 请 求 的 tracing ° 


"E R40 Emm I 


Find Traces Vs 
5 a 
Service (2 doom B C Q 
customer 
200m 
Operation e ^ 
all 03:20:00 pm 03:36:40 pm 03:53:20 pm 
Tags 
14 Traces Sort: Most Recent 
Lookback customer: getCustomer 445.24ms 
Last Hour 4 Spans B customer (2) preference (2) Today 4:01:36 pm 
5 minutes ago 
Min Duration 
customer: GET 37.08ms 
Max Duration PEE B customer (2) Today 3:17:35 pm 
an hour ago 
: 38.59ms 
Limit Results customer: getCustomer 
20 4 Spans B customer (2) preference (2) Today | 3:17:35 pm 
an hour ago 
Find Traces 
customer: getCustomer 17.06ms 
4 Spans B customer (2) preference (2) Today 3:17:35 pm 
an hour ago 
source https:/jimmysong.io 
customer: getCustomer 31ms 


E A - Jaeger query UI 


构建 镜像 


在 本 地 运行 测试 无 误 之 后 就 可 以 构建 镜像 了 。 本 教程 中 的 容器 镜像 都 是 在 
fabric8/java-jboss-openjdk8-jdk 的 基础 上 构建 的 。 只 要 将 Java 应 用 构建 出 Jar 包 
然后 放 到 /deployments 目录 下 基础 镜像 就 可 以 自动 帮 有 我 们 运行 ， 所 以 我 们 看 到 
着 几 个 应 用 的 Dockerfile 文件 中 都 没有 执行 入 口 ， 丨 正 的 执行 入 口 是 run- 
java.sh ° 


Customer 


构建 Customer 镜像 。 


cd customer/java/springboot 

mvn clean package 

docker build -t jimmysong/istio-tutorial-customer:v1 
docker push jimmysong/istio-tutorial-customer:v1 


第 一 次 构建 和 上 传 需要 花费 一 点 时 间 ， 下 一 次 构建 就 会 很 快 


Preference 


构建 Preference 镜像 。 


cd preference/java/springboot 
mvn clean package 


docker build -t jimmysong/istio-tutorial-preference:v1 . 
docker push jimmysong/istio-tutorial-preference:v1 


Recommendation 


构建 Recommendation 镜像 。 


cd recommendation/java/vertx 
mvn clean package 


docker build -t jimmysong/istio-tutorial-recommendation:v1 . 
docker push jimmysong/istio-tutorial-recommendation:v1 


现在 三 个 docker 镜像 都 构建 完成 了 ， 我 们 检查 一 下 。 


$ docker images | grep istio-tutorial 


REPOSITORY TAG 
AGE ID CREATED SIZE 
jimmysong/istio-tutorial-recommendation vi 
1dd858c300 51 seconds ago 443MB 
jimmysong/istio-tutorial-preference vi 
fobe361477 6 minutes ago 459MB 
jimmysong/istio-tutorial-customer vi 
601692673e 13 minutes ago 459MB 


部 署 到 Kubernetes 


使 用 下 面 的 命令 将 以 上 服务 部 署 到 kubernetes ° 


IM 


d3 


e5 


d9 


# create new namespace 
kubectl create ns istio-tutorial 


# deploy recommendation 

kubectl apply -f <(istioctl kube-inject -f recommendation/kubern 
etes/Deployment.yml) -n istio-tutorial 

kubectl apply -f recommendation/kubernetes/Service. yml 

# deploy preferrence 

kubectl apply -f <(istioctl kube-inject -f preference/kubernetes 
/Deployment.yml) -n istio-tutorial 

kubectl apply -f preference/kubernetes/Service.yml 

4 deploy customer 

kubectl apply -f «(istioctl kube-inject -f customer/kubernetes/D 
eployment.yml) -n istio-tutorial 

kubectl apply -f customer/kubernetes/Service.yml 


注意 : preference 和 customer 应 用 启动 速度 比较 慢 ， 我 们 将 livenessProb 
配置 中 的 initialDelaySeconds 设置 为 20 秒 。 


查看 Pod 启动 状态 : 


kubectl get pod -w -n istio-tutorial 


增加 Ingress 配置 

为 了 在 kubernetes 集群 外 部 访问 customer 服务 ， 我 们 需要 增加 ingress 配置 。 
kubectl apply -f ingress/ingress.yaml 

修改 本 地 的 /etc/hosts 文件 ， 增 加 一 条 配置 。 
172.17.8.102 customer.istio-tutorial.jimmysong.io 

现在 访问 http://customer.istio-tutorial.jimmysong.io 将 看 到 如 下 输出 : 


customer => preference => recommendation v1 from '6fc97476f8-m2n 
tp: 1 


批量 访问 该 地 址 。 


./bin/poll customer.sh 


访问 http://servicegraph.istio.jimmysong.io/dotviz 查看 服务 的 分 布 式 追 踪 和 依赖 关 
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Service Name Span Name Lookback 


customer A all v 1 hour 


Duration (us) >= 
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图 片 - 分 布 式 追 踪 
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图 片 - 依赖 关系 
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图 片 -服务 关系 图 和 QPS 


查看 Service Mesh 的 监控 信息 。 


Success Rate by Source and Version (non-5xx responses) Response Time by Source and Version Response Size by Source and Version 
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25.00% unos y d 
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- Grafana 监控 


A A 


为 了 试用 lstio 中 的 各 种 功能 ， 我 们 需要 为 应 用 构建 多 个 版 本 ， 我 们 为 
recommendation 构建 v2 版 本 的 镜像 ， 看 看 如 何 使 用 lstio 控制 微服 务 的 流量 。 


构建 recommendation:v2 


我 们 将 构建 新 版 的 recommendation 服务 的 镜像 ， 并 观察 customer 对 不 同 版 
本 的 recommendataion 服务 的 访问 频率 。 


修改 
recommendation/java/vertx/src/main/java/com/redhat/developer/demos/ 


recommendation/RecommendationVerticle.java 程序 中 代码 。 


将 private Static final String RESPONSE_STRING_FORMAT = 
"recommendation vi from '%s': %d\n"; 修改 为 private static final 
String RESPONSE_STRING_FORMAT = "recommendation v2 from '%s': 
%d\n"; 


并 构建 recommendation:v2 镜像 。 


cd recommendation/java/vertx 

mvn clean package 

docker build -t jimmysong/istio-tutorial-recommendation:v2 
docker push jimmysong/istio-tutorial-recommendation:v2 


将 应 用 部 署 到 kubernetes ° 


# deploy recommendation 
kubectl apply -f <(istioctl kube-inject -f recommendation/kubern 
etes/Deployment-v2.yml) -n istio-tutorial 


现在 再 访问 customer 服务 ， 将 看 到 如 下 输出 : 


我 们 可 以 看 到 v1 和 v2 版 本 的 
我 们 再 将 v2 版 本 的 


MZ 


观 


$ bin/poll_customer.sh 


customer => 


2¢'t 1 
customer => 
tp': 3581 
customer => 
Art 2 
customer => 
tp': 3582 
customer => 
Zr % 3 
customer => 
tp": 3583 
customer => 
27': 4 


preference 
preference 
preference 
preference 
preference 
preference 


preference 


recommendation 


recommendation 


recommendation 


recommendation 


recommendation 


recommendation 


recommendation 


v2 


v1 


v2 


v1 


v2 


v1 


v2 


from 


from 


from 


from 


from 


from 


from 


'77b9f6cc68-5xs 


'6fc97476f8-m2n 


'TTb9f6cc68-5xs 


'6fc97476f8-m2n 


'TTb9f6cc68-5xs 


'6fc97476f8-m2n 


'TTb9f6cc68-5xs 


recommendation 服务 会 被 间隔 访问 到 。 


recommendation 实例 数 设 置 成 2 个。 


kubectl scale --replicas=2 deployment/recommendation-v2 -n istio 


-tutorial 


kubectl get pod -w -n istio-tutorial 


E 


$ bin/poll customer.sh 


customer => 
gj': 1 
customer => 
27 a Tå 
customer => 


tp': 3651 
customer => 
gj': 2 
customer => 
27': 72 
customer => 
tp': 3652 
customer => 
gj': 3 


customer => 
27 T3 
customer => 
tp': 3653 


W 


preference 
preference 
preference 
preference 
preference 
preference 
preference 
preference 


preference 


recommendation-v2 Pod 


达到 两 个 之 后 再 访问 customer 服务 。 


recommendation 


recommendation 


recommendation 


recommendation 


recommendation 


recommendation 


recommendation 


recommendation 


recommendation 


V2 


v2 


v1 


v2 


v2 


v1 


v2 


v2 


v1 


from 


from 


from 


from 


from 


from 


from 


from 


from 


察 输出 中 v1 和 V2 版 本 recommendation 的 访问 频率 。 


'77b9f6cc68- j9F 
'77b9f6cc68-5xs 
'6fc97476f8-m2n 
'77b9f6cc68- j9f 
'7ZTb9f6cc68-5xs 
'6fc97476f8-m2n 
'77b9f6cc68- j9f 
'77b9f6cc68-5xs 


'6fc97476f8-m2n 


将 recommendataion 服务 的 实例 数 恢 复 为 1。 


kubectl scale --replicas=1 deployment/recommendation-v2 


修改 Istio RouteRules 


以 下 所 有 路 有 规则 都 是 针对 recommendation 服务 ， 并 在 repo 的 根 目 录 下 执 


>- 
o 


将 所 有 流量 打 给 v2 
下 面 将 演示 如 何 动态 的 划分 不 同 版 本 服务 间 的 流量 ， 将 所 有 的 流量 都 打 到 


recommendation:v2 ° 


istioctl create -f istiofiles/route-rule-recommendation-v2.yml - 
n istio-tutorial 


现在 再 访问 customer 服务 将 看 到 所 有 的 流量 都 会 打 到 recommendation:v2 ° 


删除 RouteRules 后 再 访问 customer 服务 将 看 到 又 恢复 了 v1 和 v2 版 本 的 


recommendation 服务 的 间隔 访问 。 


istioctl delete routerule recommendation-default 


al 


切 分 流 


将 90% 的 流量 给 V1， 10% 的 流量 给 v2 ° 


istioctl create -f istiofiles/route-rule-recommendation-vi and v 
2.yml -n istio-tutorial 


4? 


执行 bin/poll customer.sh 观察 访问 情况 。 


要 想 动 态 切 分 流量 只 要 修改 RouteRules 中 的 weight 配置 即 可 。 


apiVersion: config.istio.io/vialpha2 
kind: RouteRule 
metadata: 
name: recommendation-vi-v2 
spec: 
destination: 
namespace: istio-tutorial 
name: recommendation 
precedence: 5 


route: 
- labels: 
version: vi 
weight: 90 
- labels: 
version: v2 
weight: 10 


因为 RouteRule 有 优先 级 ， 为 了 继续 后 面 的 实验 ， 在 验证 完成 后 删除 该 
RouteRule。 


istioctl delete routerule recommendation-vi-v2 -n istio-tutorial 


故障 注入 


有 时 候 我 们 为 了 增强 系统 的 健壮 性 ， 需 要 对 系统 做 混沌 工程 ， 故 意 注入 故障 ， 并 保 
障 服务 可 以 自动 处 理 这 些 故 障 。 


注入 HTTP 503 错误 


istioctl create -f istiofiles/route-rule-recommendation-503.yml 
-n istio-tutorial 


有 5096 的 几率 报 503 错误 。 


$ bin/poll_customer.sh 

customer => preference => recommendation v2 from '77b9f6cc68-5xs 
27': 135 

customer => 503 preference => 503 fault filter abort 

customer => preference => recommendation v1 from '6fc97476f8-m2n 
tp': 3860 

customer => 503 preference => 503 fault filter abort 

customer => 503 preference => 503 fault filter abort 

customer => preference => recommendation v2 from '77b9f6cc68-5xs 
27': 136 

customer => preference => recommendation v1 from '6fc97476f8-m2n 
tp': 3861 

customer -» 503 preference -» 503 fault filter abort 

customer -» 503 preference -» 503 fault filter abort 

customer -» preference -» recommendation v2 from '77b9f6cc68-5xs 
27': 137 

customer => 503 preference => 503 fault filter abort 


清理 RouteRule ° 


istioctl delete routerule recommendation-503 -n istio-tutorial 


28 yo KE 3R 
增加 服务 的 访问 延迟 。 


istioctl create -f istiofiles/route-rule-recommendation-delay.ym 
l -n istio-tutorial 


会 有 50% 的 几率 访问 recommendation 服务 有 7 秒 的 延迟 。 百 分 比 和 延迟 时 间 
可 以 在 RouteRule 中 配置 。 


清理 RouteRule。 


istioctl delete routerule recommendation-delay -n istio-tutorial 


重 试 


让 服务 不 是 直接 失败 ， 而 是 增加 重 试 机 制 。 


我 们 下 面 将 同时 应 用 两 条 RouteRule， 让 访问 recommendation 服务 时 有 50% 
的 几率 出 现 503 错误 ， 并 在 出 现 错误 的 时 候 尝试 访问 v2 版 本 ， 超 时 时 间 为 2 秒 。 


istioctl create -f istiofiles/route-rule-recommendation-v2_503.y 
ml -n istio-tutorial 

istioctl create -f istiofiles/route-rule-recommendation-v2_retry 
.yml -n istio-tutorial 


执行 bin/poll customer.sh 我 们 看 到 一 开始 有 些 503 错误 ， 然 后 所 有 的 流量 
都 流向 了 v2 


清理 RouteRules。 


istioctl delete routerule recommendation-v2-retry -n istio-tutor 
ial 

istioctl delete routerule recommendation-v2-503 -n istio-tutoria 
1 


超时 

设置 超时 时 间 ， 只 有 服务 访问 超时 才 认 定 服务 访问 失败 。 

取消 注释 
recommendation/java/vertx/src/main/java/com/redhat/developer/demos/ 


recommendation/RecommendationVerticle.java 中 的 下 面 一 行 ， 增 加 超时 时 间 
为 3 秒 。 


router.get("/").handler(this::timeout); 
重新 生成 镜像 。 


cd recommendation/java/vertx 

mvn clean package 

docker build -t jimmysong/istio-tutorial-recommendation:v2 
docker push jimmysong/istio-tutorial-recommendation:v2 


重新 部 署 到 kubernetes ° 


kubectl delete -f recommendation/kubernetes/Deployment-v2.yml 


因为 我 们 重新 构建 的 镜像 使 用 了 同样 的 名 字 和 tag， 而 之 前 在 Deployment- 
v2.yml 中 配置 的 镜像 拉 取 策略 是 IfNotPresent ， 这 样 的 话 即 使 我 们 构建 了 新 
的 镜像 也 无 法 应 用 到 集群 上 ， 因 此 将 镜像 拉 取 策略 改 成 Always 确保 每 次 启动 
Pod 的 时 候 都 会 拉 取 镜像 。 


kubectl apply -f <(istioctl kube-inject -f recommendation/kubern 
etes/Deployment-v2.yml) -n istio-tutorial 


启用 超时 RouteRules ° 


istioctl create -f istiofiles/route-rule-recommendation-timeout. 
yml -n istio-tutorial 


访问 customer 服务 将 看 到 如 下 输出 : 


$ bin/poll_customer.sh 

customer => 503 preference => 504 upstream request timeout 
customer => preference => recommendation v1 from '6fc97476f8-m2n 
tp': 4002 

customer => 503 preference => 504 upstream request timeout 
customer => preference => recommendation v1 from '6fc97476f8-m2n 
tp': 4003 

customer => 503 preference => 504 upstream request timeout 
customer => preference => recommendation v1 from '6fc97476f8-m2n 
tp': 4004 


清理 RouteRules ° 


istioctl delete routerule recommendation-timeout -n istio-tutori 
al 


基于 user-agent 的 智能 路 由 (SARA ) 


User-agent 是 一 个 字符 串 ， 其 中 包含 了 浏览 器 的 信息 ， 访 问 
https://www.whoishostingthis.com/tools/user-agent 获取 你 的 user-agent ° 


我 的 User-agent 是 


Mozilla/5.0 (Macintosh; Intel Mac OS X 10 13 4) AppleWebKit/537. 
36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36 


将 所 有 的 流量 打 到 v1» 


istioctl create -f istiofiles/route-rule-recommendation-v1.yml - 
n istio-tutorial 


将 使 用 Safari 浏览 器 访问 的 流量 打 到 v2» 


istioctl create -f istiofiles/route-rule-safari-recommendation-v 
2.yml -n istio-tutorial 


谁 用 Safari 或 者 Chrome (Chrome 浏览 器 的 user-agent 中 也 包含 Safari FE) 7 
问 http://customer.istio-tutorial.jimmysong.io/ 在 经 过 3 秒 钟 (我 们 在 前 MM 
v2 镜像 ， 设 置 了 3 秒 超 时 时 间 ) 后 将 看 到 访问 v2 的 输出 。 


或 者 使 用 curl 访问 。 


curl -A Safari http://customer.istio-tutorial.jimmysong.io/ 
curl -A Firefox http://customer.istio-tutorial.jimmysong.io/ 


观察 返回 的 结果 。 


将 移动 端 用 户 的 流量 导 到 V2。 


istioctl create -f istiofiles/route-rule-mobile-recommendation-v 
2.yml -n istio-tutorial 


curl -A "Mozilla/5.0 (iPhone; U; CPU iPhone OS 4(KHTML, like Gec 
ko) Version/5.0.2 Mobile/8J2 Safari/6533.18.5" http://customer.i 
stio-tutorial.jimmysong.io/ 


观察 输出 的 结果 。 


清理 RouteRules。 


istioctl delete routerule recommendation-mobile -n istio-tutoria 
1 
istioctl delete routerule recommendation-safari -n istio-tutoria 
1 
istioctl delete routerule recommendation-default -n istio-tutori 
al 


镜像 流量 
确保 当前 至 少 运 行 了 两 个 版 本 的 recommendation 服务 ， 并 且 没 有 RouteRule 。 
it: 可 以 使 用 istioctl get routerule 获取 RouteRule。 


设置 流量 镜像 ， 将 所 有 v1 的 流量 都 被 镜像 到 V2 © 


istioctl create -f istiofiles/route-rule-recommendation-vi-mirro 
r-v2.yml -n istio-tutorial 
bin/poll_customer.sh 


查看 recommendation-v2 的 日 志 。 


kubectl logs -f ‘oc get pods|grep recommendation-v2|awk '{ print 
$1 }'` -c recommendation 


B[————————————————————————— À—— Á—9m—] 
访问 控制 


Istio 可 以 设置 服务 访问 的 黑白 名 单 ， 如 果 没 有 权限 的 话 会 返回 HTTP 404 Not 
Found ° 


白 名 单 


istioctl create -f istiofiles/acl-whitelist.yml -n istio-tutoria 
1 


此 时 访问 customer 服务 。 


$ bin/poll_customer.sh 
customer => 404 NOT FOUND:preferencewhitelist.listchecker.istio- 
tutorial:customer is not whitelisted 


重 置 环境 。 


istioctl delete -f istiofiles/acl-whitelist.yml -n istio-tutoria 
1 


黑 名 单 


设置 黑 名 单 ， 所 有 位 于 黑 名 单 中 的 流量 将 获得 403 Forbidden 返回 码 。 


istioctl create -f istiofiles/acl-blacklist.yml -n istio-tutoria 
1 


此 时 访问 customer 服务 。 


$ bin/poll_customer.sh 
customer => 403 PERMISSION DENIED:denycustomerhandler.denier.ist 


io-tutorial:Not allowed 


重 置 环境 。 


istioctl delete -f istiofiles/acl-blacklist.yml -n istio-tutoria 
1 


负载 均衡 


Kubernetes 中 默认 的 负载 均衡 策略 是 round-robin， 当 然 我 们 可 以 使 用 Istio 把 它 修 
改 成 random。 


增加 Vv1 的 实例 数 。 


kubectl scale deployment recommendation-v1 --replicas-2 -n istio 
-tutorial 


持续 访问 customer 服务 。 

bin/poll_customer.sh 
保持 前 台 输 出 ， 观 察 流量 的 行为 。 
应 用 负载 均衡 策略 。 


istioctl create -f istiofiles/recommendation lb policy app.yml - 
n istio-tutorial 


观察 一 段 时 间 流 量 的 行为 后 ， 重 置 环 境 。 


istioctl delete -f istiofiles/recommendation lb policy app.yml - 
n istio-tutorial 

kubectl scale deployment recommendation-vi1 --replicas-1 -n istio 
-tutorial 


速率 限制 


暂时 不 可 用 


BT IS ds 


当 达 到 最 大 连接 数 和 最 大 挂 起 请 求 数 时 快速 失败 。 


将 流量 在 v1 和 V2 之 间 均 分 。 


istioctl create -f istiofiles/route-rule-recommendation-vi and v 
2 50 50.yml -n istio-tutorial 


未 开局 断路 器 的 时 候 启 动 负载 测试 。 


$ siege -r 2 -c 20 -v customer.istio-tutorial.jimmysong.io 
New configuration template added to /Users/jimmysong/.siege 
Run siege -C to view the current settings in that file 

** SIEGE 4.0.4 

** Preparing 20 concurrent users for battle. 

The server is now under siege... 


HTTP/1.1 200 0.10 secs: 75 bytes ==> GET / 
HTTP/1.1 200 0.12 secs: 75 bytes --» GET / 
HTTP/1.1 200 0.13 secs: 75 bytes ==> GET / 
HTTP/1.1 200 0.13 secs: 75 bytes ==> GET / 
HTTP/1.1 200 0.13 secs: 75 bytes ==> GET / 
HTTP/1.1 200 0.17 secs: 75 bytes ==> GET / 
HTTP/1.1 200 3.12 secs: 74 bytes ==> GET / 
HTTP/1.1 200 3.14 secs: 75 bytes ==> GET / 
HTTP/1.1 200 3.15 secs: 74 bytes ==> GET / 
HTTP/1.1 200 3.15 secs: 74 bytes ==> GET / 
HTTP/1.1 200 3.17 secs: 75 bytes ==> GET / 
HTTP/1.1 200 3.17 secs: 75 bytes ==> GET / 
HTTP/1.1 200 3.20 secs: 75 bytes ==> GET / 
HTTP/1.1 200 3.20 secs: 74 bytes ==> GET / 
HTTP/1.1 200 0.05 secs: 75 bytes ==> GET / 
HTTP/1.1 200 0.12 secs: 75 bytes ==> GET / 


HTTP/1.1 200 3.15 secs: 75 bytes ==> GET / 
HTTP/1.1 200 3.25 secs: 75 bytes ==> GET / 
HTTP/1.1 200 3.26 secs: 75 bytes ==> GET / 
HTTP/1.1 200 3.14 secs: 75 bytes ==> GET / 
HTTP/1.1 200 3.58 secs: 74 bytes ==> GET / 
HTTP/1.1 200 6.15 secs: 74 bytes ==> GET / 
HTTP/1.1 200 6.16 secs: 75 bytes ==> GET / 
HTTP/1.1 200 3.03 secs: 74 bytes ==> GET / 
HTTP/1.1 200 6.06 secs: 75 bytes ==> GET / 
HTTP/1.1 200 6.04 secs: 75 bytes ==> GET / 
HTTP/1.1 200 3.11 secs: 74 bytes ==> GET / 
HTTP/1.1 200 3.09 secs: 75 bytes ==> GET / 
HTTP/1.1 200 6.15 secs: 74 bytes ==> GET / 
HTTP/1.1 200 6.71 secs: 74 bytes ==> GET / 
HTTP/1.1 200 3.52 secs: 75 bytes ==> GET / 
AC 

Lifting the server siege... 

Transactions: 31 hits 

Availability: 100.00 % 

Elapsed time: 7.99 secs 

Data transferred: 0.00 MB 

Response time: 2.99 secs 

Transaction rate: 3.88 trans/sec 
Throughput: 0.00 MB/sec 

Concurrency: 11.60 

Successful transactions: 31 

Failed transactions: 9 

Longest transaction: 6.71 

Shortest transaction: 0.05 


所 有 的 请 求 都 成 功 了 ， 但 是 性 能 很 差 ， 因 为 v2 版 本 设置 了 3 秒 的 超时 时 间 。 
我 们 启用 下 断路 器 。 


istioctl create -f istiofiles/recommendation cb policy version v 
2.yml -n istio-tutorial 


重新 测试 一 下 。 


$ siege -r 2 -c 20 -v customer.istio-tutorial.jimmysong.io 
** SIEGE 4.0.4 

** Preparing 20 concurrent users for battle. 

The server is now under siege... 


HTTP/1.1 200 0.07 secs: 75 bytes ==> GET / 
HTTP/1.1 503 0.07 secs: 92 bytes ==> GET / 
HTTP/1.1 200 0.07 secs: 75 bytes ==> GET / 
HTTP/1.1 503 0.12 secs: 92 bytes --» GET / 
HTTP/1.1 503 0.12 secs: 92 bytes --» GET / 
HTTP/1.1 200 0.16 secs: 75 bytes ==> GET / 


HTTP/1.1 503 0.16 secs: 92 bytes ==> GET 
HTTP/1.1 503 0.21 secs: 92 bytes ==> GET 
HTTP/1.1 503 0.21 secs: 92 bytes ==> GET 
HTTP/1.1 200 0.24 secs: 75 bytes ==> GET 
HTTP/1.1 200 0.24 secs: 75 bytes ==> GET 
HTTP/1.1 503 0.14 secs: 92 bytes ==> GET 
HTTP/1.1 503 0.29 secs: 92 bytes ==> GET 
HTTP/1.1 503 0.13 secs: 92 bytes ==> GET 
HTTP/1.1 503 0.18 secs: 92 bytes ==> GET 
HTTP/1.1 503 0.13 secs: 92 bytes ==> GET 
HTTP/1.1 200 0.11 secs: 75 bytes ==> GET 
HTTP/1.1 200 0.39 secs: 75 bytes ==> GET 
HTTP/1.1 200 0.24 secs: 75 bytes ==> GET 
HTTP/1.1 503 0.44 secs: 92 bytes ==> GET 
HTTP/1.1 200 0.43 secs: 75 bytes ==> GET 
HTTP/1.1 200 0.44 secs: 75 bytes ==> GET 
HTTP/1.1 503 0.40 secs: 92 bytes ==> GET 
HTTP/1.1 200 0.47 secs: 75 bytes ==> GET 
HTTP/1.1 503 0.42 secs: 92 bytes ==> GET 
HTTP/1.1 200 0.42 secs: 75 bytes ==> GET 
HTTP/1.1 200 0.06 secs: 75 bytes ==> GET 
HTTP/1.1 503 0.07 secs: 92 bytes ==> GET 
HTTP/1.1 200 0.15 secs: 75 bytes ==> GET 
HTTP/1.1 200 0.12 secs: 75 bytes ==> GET 
HTTP/1.1 503 0.57 secs: 92 bytes ==> GET 
HTTP/1.1 503 0.18 secs: 92 bytes ==> GET 
HTTP/1.1 503 0.52 secs: 92 bytes ==> GET 
HTTP/1.1 503 0.65 secs: 92 bytes ==> GET 
HTTP/1.1 503 0.42 secs: 92 bytes ==> GET 
HTTP/1.1 200 0.09 secs: 75 bytes ==> GET 
HTTP/1.1 200 0.43 secs: 75 bytes ==> GET 
HTTP/1.1 503 0.04 secs: 92 bytes ==> GET 
HTTP/1.1 200 4.15 secs: 74 bytes --» GET 
HTTP/1.1 200 0.01 secs: 75 bytes --» GET 
Transactions: 19 hits 
Availability: 47.50 96 

Elapsed time: 4.16 secs 

Data transferred: 0.00 MB 

Response time: 0.72 secs 
Transaction rate: 4.57 trans/sec 
Throughput: 0.00 MB/sec 
Concurrency: 3.31 

Successful transactions: 19 

Failed transactions: 21 

Longest transaction: 4.15 

Shortest transaction: 0.01 


我 们 可 以 看 到 在 局 用 了 断路 器 后 各 项 性 能 都 有 提高 。 


清理 配置 。 


TV CV we NN NY Mw ME NY MW RR RR RR NN NR RR MS Ny 


istioctl delete routerule recommendation-vi-v2 -n istio-tutorial 
istioctl delete -f istiofiles/recommendation cb policy version v 
2.yml -n istio-tutorial 


Pool Ejection 


所 谓 的 Pool Ejection 就 是 当 某 些 实例 出 现 错误 (如 返回 5xx 错误 码 ) 临时 将 该 实 
例 弹 出 一 段 时 间 后 (窗口 期 ， 可 配置 ) ， 然 后 再 将 其 加 入 到 负载 均衡 池 中 。 我 们 的 
例子 中 配置 的 窗口 期 是 15 秒 。 


1% v1 和 v2 的 流量 均 分 。 


istioctl create -f istiofiles/route-rule-recommendation-vi and v 
2 50 50.yml -n istio-tutorial 


增加 V2 的 实例 个 数 。 


kubectl scale deployment recommendation-v2 --replicas=2 -n istio 
-tutorial 
kubectl get pods -w 


等 待 所 有 的 Pod 的 状态 都 启动 完成 。 
现在 到 v2 的 容器 中 操作 。 


$ kubectl exec recommendation-v2-785465d9cd-225ms -c recommendat 
ion /bin/bash 

$ curl localhost:8080/misbehave 

Following requests to '/' will return a 503 


增加 Pool Ejection 配置 。 


istioctl create -f istiofiles/recommendation_cb_policy_pool_ejec 
tion.yml -n istio-tutorial 


此 时 再 访问 customer 服务。 


$ bin/poll_customer.sh 

customer => preference => recommendation v1 from '6fc97476f8-m2n 
tp': 10505 

customer => preference => recommendation v2 from '785465d9cd-225 
ms': 2407 

customer => preference => recommendation v1 from '6fc97476f8-m2n 
tp': 10506 

customer => preference => recommendation v2 from '785465d9cd-225 
ms': 2408 

customer => preference => recommendation v1 from '6fc97476f8-m2n 


tp': 10507 
customer => preference => recommendation v1 from '6fc97476f8-m2n 
tp': 10508 
customer => preference => recommendation v1 from '6fc97476f8-m2n 
tp': 10509 


customer -» 503 preference -» 503 recommendation misbehavior fro 
m '785465d9cd-1dc6j' 

customer -» preference -» recommendation v2 from '785465d9cd-225 
ms': 2409 

customer -» preference -» recommendation v2 from '785465d9cd-225 
ms': 2410 


我 们 看 到 窗口 期 生效 了 ， 当 出 现 503 错误 后 至 少 15 秒 后 才 会 出 现 第 二 次 


即使 有 了 负载 均衡 池 弹出 策略 对 于 系统 的 弹性 来 说 依然 还 不 够 ， 如 果 你 的 服务 有 多 
个 可 用 实例 ， 可 以 将 断路 器 、 重 试 、Pool Ejection 等 策略 组 合 起 来 使 用 。 


例如 在 以 上 的 Pool Ejection 的 基础 上 增加 重 试 策略 。 


istioctl replace -f istiofiles/route-rule-recommendation-vi_and_ 
v2_retry.yml -n istio-tutorial 


现在 再 访问 customer 服务 就 看 不 到 503 错误 了 。 


清理 配置 。 


kubectl scale deployment recommendation-v2 --replicas=1 -n istio 
-tutorial 

istioctl delete routerule recommendation-vi-v2 -n istio-tutorial 
istioctl delete -f istiofiles/recommendation_cb_policy_pool_ejec 
tion.yml -n istio-tutorial 


Egress 


Egress 是 用 来 配置 |stio serivce mesh 中 的 服务 对 外 部 服务 的 访问 策略 。 
具体 配置 请 参考 控制 Egress 流量 。 
以 下 示例 还 有 问题 ， 无 法 正常 工作 。 


构建 示例 镜像 egresshttpbin ° 


cd egress/egresshttpbin/ 

mvn clean package 

docker build -t jimmysong/istio-tutorial-egresshttpbin:vi . 
docker push jimmysong/istio-tutorial-egresshttpbin: v1 


部 署 到 Kubernetes ° 


kubectl apply -f <(istioctl kube-inject -f egress/egresshttpbin/ 
src/main/kubernetes/Deployment.yml) -n istio-toturial 

kubectl create -f egress/egresshttpbin/src/main/kubernetes/Servi 
ce.yml 


为 了 在 kubernetes 集群 外 部 访问 到 该 服务 ， 修 改 增 加 ingress 配置 并 修改 本 地 
的 /etc/hosts 文件 ， 我 们 在 前 面 已 经 完成 了 ， 此 处 不 再 歼 述 。 


构建 示例 镜像 egressgithub 。 


cd egress/egressgithub 

mvn clean package 

docker build -t jimmysong/istio-tutorial-egressgithub:v1 . 
docker push jimmysong/istio-tutorial-egressgithub: vi 


部 署 到 Kubernetes 。 


kubectl apply -f <(istioctl kube-inject -f egress/egressgithub/s 
rc/main/kubernetes/Deployment.yml) -n istio-tutorial 

kubectl create -f egress/egressgithub/src/main/kubernetes/Servic 
e.yml 


增加 Egress 配置 。 


istioctl create -f istiofiles/egress_httpbin.yml -n istio-tutori 
al 


到 egresshttpbin 容器 中 测试 。 


kubectl exec -it $(oc get pods -o jsonpath="{.items[*].metadata. 
name?" -l app=egresshttpbin, version=v1) -c egresshttpbin /bin/ba 
sh 


curl localhost:8080 
curl httpbin.org/user-agent 
curl httpbin.org/headers 


exit 


增加 对 jimmysong.io 的 egress 配置 。 


cat <<EOF | istioctl create -f - 
apiVersion: config.istio.io/vialpha2 
kind: EgressRule 
metadata: 
name: jimmysong-egress-rule 
namespace: istio-tutorial 
spec: 
destination: 
service: jimmysong.io 
ports: 
- port: 443 
protocol: https 
EOF 


增加 Egress 配置 。 


istioctl create -f istiofiles/egress_github.yml -n istio-tutoria 
1 


到 egressgithub 容器 中 测试 。 


kubectl exec -it $(oc get pods -o jsonpath="{.items[*].metadata. 
name?" -l app=egressgithub, version=v1) -c egressgithub /bin/bash 


curl http://jimmysong:443 


exit 


清理 环境 。 


istioctl delete egressrule httpbin-egress-rule jimmysong-egress- 
rule github-egress-rule -n istio-tutorial 


e https://github.com/redhat-developer-demos/istio-tutorial 
e Book - Introducing Istio Service Mesh for Microservices 
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Linkerd 简介 


Linkerd 是 一 个 用 于 云 原 生 应 用 的 开源 、 可 扩展 的 service mesh (一 般 翻 译 成 服务 网 
各 ， 还 有 一 种 说 法 叫 " 服 务 哮 合 层 "， 见 lstio : 用 于 微服 务 的 服务 吐 合 层 ) 。 


Linkerd 有 是 什么 


Linkerd 的 出 现 是 为 了 解决 像 twitter、google 这 类 超大 规模 生产 系统 的 复杂 性 问题 。 
Linkerd 不 是 通过 控制 服务 之 间 的 通信 机 制 来 解决 这 个 问题 ， 而 是 通过 在 服务 实例 之 
上 添加 一 个 抽象 层 来 解决 的 。 


application 
service instance 
discovery 


jialanced RP( 


destination 
instances 





图 片 - source https-//linkerd.io 


Linkerd 负 责 跨 服务 通信 中 最 困难 、 易 出 错 的 部 分 ， 包 括 延迟 感知 、 负 载 平衡 、 连 接 
池 、TLS、 仅 表盘 、 请 求 路 由 等 这些 都 会 影响 应 用 程序 伸缩 性 、 性 能 和 弹性 。 


如 何 运 行 


Linkerd 作 为 独立 代理 运行 ， 无 需 特 定 的 语言 和 库 支 持 。 应 用 程序 会 在 已 知 位 置 
运行 |inkerd 实 例 ， 然 后 通过 这 些 实例 tn Ep ne E ds AR 
务 ， 服 务 连 接 到 它们 对 应 的 linkerd 实 例 ， 并 将 它们 视 为 目标 服务 。 


在 该 层 上 ，linkerd 应 用 路 由 规则 ， 与 现 有 服务 发 现 机 制 通信 ， 对 目标 实例 做 负载 均 
衡 一 一 与 此 同时 调整 通信 并 报告 指标 。 


通过 延迟 调用 linkerd 的 机 制 ， 应 用 程序 代码 与 以 下 内 容 解 耦 : 


e 生产 拓扑 
e 服务 发 现 机 制 
e 负载 均衡 和 连接 管理 逻辑 


应 用 程序 也 将 从 一 致 的 全 局 流量 控制 系统 中 受益 。 这 对 于 多 语言 应 用 程序 尤其 重 
要 ， 因 为 通过 库 来 实现 这 种 一 致 性 是 非常 困难 的 。 

Linkerd 实 例 可 以 作为 sidecar (了 既 为 每 个 应 用 实体 或 每 个 主机 部 署 一 个 实例 ) 来 运 
行 。 由 于 linkerd 实 例 是 无 状态 和 独立 的 ， 因 此 它们 可 以 轻松 适应 现 有 的 部 署 拓扑 。 
它们 可 以 与 各 种 配置 的 应 用 程序 代码 一 起 部 署 ， 并 且 基 本 不 需要 去 协调 它们 。 


详解 


Linkerd 的 基于 Kubernetes 的 Service Mesh 部 署 方式 是 使 用 Kubernetes 中 的 
DaemonSet 资源 对 象 ， 如 下 图 所 示 。 


Linkerd 


Host 1 Host 2 


Pod H 
application application application application 
Pod J 


application application application application 
Pod L 


application application application application 





图 片 - Linkerd 部 署 架 构 (A A & B https://buoyant.io/2016/10/14/a-service-mesh- 
for-kubernetes-part-ii-pods-are-great-until-theyre-not/) 


这 样 Kubernetes 集群 中 的 每 个 节点 都 会 运行 一 个 Linkerd 的 Pod 。 
但 是 这 样 做 就 会 有 几 个 问题 : 


e 节点 上 的 应 用 如 何 发 现 其 所 在 节点 上 的 Linkerd %? 

e 节点 间 的 Linkerd 如 何 路 由 的 呢 ? 

e Linkerd 如 何 将 接收 到 的 流量 路 由 到 正确 的 目的 应 用 呢 ? 
e 如 何 对 应 用 的 路 有 做 细 粒 度 的 控制 ? 


这 几 个 问题 在 Buoyant 公司 的 这 篇 博客 中 都 有 解答 : A Service Mesh for 
Kubernetes, Part Il: Pods are great until they're not， 我 们 下 面 将 简要 的 回答 上 述 
问题 。 


节点 上 的 应 用 如 何 发 现 其 所 在 节点 上 的 Linkerd % ? 
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简 而 言 之 ， 是 使 用 环境 变量 的 方式 ， 如 在 应 用 程序 中 注入 环境 变量 
http_proxy 


env: 
- name: NODE_NAME 

valueFrom: 

fieldRef: 
fieldPath: spec.nodeName 

- name: http proxy 

value: $(NODE NAME):4140 
args: 
- "-addrz:7777" 
- "-text=Hello" 
- "-target=world" 


这 要 求 应 用 程序 必须 支持 该 环境 变量 ， 为 应 用 程序 所 在 的 Pod 设置 了 一 个 代理 ， 实 
际 上 对 于 每 种 不 同 的 协议 Linkerd 都 监听 不 同 的 端口 。 


e 4140 for HTTP 
e 4240 for HTTP/2 
e 4340 for gRPC 


关于 Linkerd 作为 Service Mesh 的 详细 配置 请 参考 serivcemesh.yml » 


节点 间 的 Linkerd 如 何 路 由 的 以 及 Linkerd 如 何 将 接 
收 到 的 流量 路 由 到 正确 的 目的 应 用 呢 ? 


通过 transformer 来 确定 节点 问 的 Linkerd 路 由 ， 参 考 下 面 的 配置 : 


routers: 
- protocol: http 
label: outgoing 
interpreter: 
kind: default 
transformers: 
- kind: io.l5d.k8s.daemonset 
namespace: default 
port: incoming 
service: 15d 


Router 定义 Linkerd 如 何 实际 地 处 理 流量 。Router 监听 请 求 并 在 这 些 请 求 上 应 用 路 
有 规则 ， 代 理 这 些 请 求 到 正确 的 目的 地 。Router 是 与 协议 相关 的 。 对 于 每 个 
Router 都 需要 定义 一 个 incoming router 和 一 个 outcoming router。 预 计 该 应 用 程 


Linkerd 


序 将 流量 发 送 到 outcoming router > 3X outcoming router 将 其 代理 到 目标 服务 节点 
上 运行 的 Linkerd 的 incoming router ° Incoming router 后 将 请 求 代理 给 目标 应 用 程 
序 本 身 。 我 们 还 定义 了 HTTP 和 HTTP/2 incoming router ， 它 们 充当 Ingress 

controller 并 基于 Ingress 资源 进行 路 由 。 


如 何 对 路 由 规则 做 细 粒 度 的 控制 呢 ? 
路 由 规则 配置 是 在 namerd 中 进行 的 ， 例 如 


$ namerctl dtab get internal 
# version MjgzNjk5NzI= 


/Srv => /#/i0.15d.k8s/default/http ; 
/host => /Srv ; 
/tmp => /srv ; 
/ SVC => /host ; 


/host/world => /srv/world-v1 ; 


Namerd 中 存储 了 很 多 dtab 配置 ， 通 过 这 些 配 置 来 管理 路 有 规则 ， 实 现 微服 务 的 流 


量 管理 。 





L5d-dtab: /s/foo => /srv/alex-foo 


图 片 -基于 dtab 的 路 由 规则 配置 阶段 发 布 


如 果 将 Linkerd 作为 边缘 节点 还 可 以 充当 Ingress controller， 如 下 图 所 示 。 


1114 


Linkerd 


External Traffic 





ConfigMap “I5d-config” Secret "ingress-certs" ll 


DaemonSet "I5d* 





4 
-Ingress “hello-world” 











Replication Controller "world" Replication Controller "world-v2” 


图 片 Linkerd ingress controller 


Linkerd 自己 最 令 人 称道 的 是 它 在 每 台 主 机 上 只 安装 一 个 Pod， 如 果 使 用 Sidecar 
模式 会 为 每 个 应 用 程序 示例 沈 都 运行 一 个 容器 ， 这 样 会 导致 过 多 的 资源 消 

耗 。Squeezing blood from a stone: small-memory JVM techniques for 
microservice sidecars 这 篇 文章 中 详细 说 明了 Linkerd 的 资源 消耗 与 性 能 。 


e A Service Mesh for Kubernetes, Part Il: Pods are great until they're not 

e Squeezing blood from a stone: small-memory JVM techniques for 
microservice sidecars 

e Buoyant 发 布 服务 网 格 Linkerd 的 1.0 版 本 
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e Linkerd documentation 
e |stio : A THIR 2-8 HR. A 9E 
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Linkerd 使 用 指南 


本 文 是 Linkerd 使 用 指南 ， 我 们 着 重 讲解 在 kubernetes 中 如 何 使 用 linkerd 作为 
kubernetes 的 Ingress controller ° 


Linkerd 作为 一 款 service mesh 4kubernetes 结合 后 主要 有 以 下 几 种 用 法 : 


.作为 服务 网 关 ， 可 以 监控 kubernetes 中 的 服务 和 实例 

. 使 用 TLS Je BRS 

. 通过 流量 转移 到 持续 交付 

.开发 测试 环境 (Eat your own dog food) ` Ingress 和 边缘 路 由 
. 给 微服 务 做 staging 

分 布 式 tracing 

.作为 Ingress controller 

. 使 用 gRPC 更 方便 


oN ONAN 


以 下 我 们 着 重 讲解 在 kubernetes 中 如 何 使 用 linkerd 作为 kubernetes 的 Ingress 
controller， 并 作为 边缘 节点 代替 Traefik 的 功能 ， 详 见 边缘 节点 的 配置 。 


准备 
安装 测试 时 需要 用 到 的 镜像 有 : 


buoyantio/helloworld:0.1.4 
buoyantio/jenkins-plus:2.60.1 
buoyantio/kubectl:v1.4.0 
buoyantio/linkerd:1.1.2 
buoyantio/namerd:1.1.2 
buoyantio/nginx:1.10.2 
linkerd/namerct1:0.8.6 
openzipkin/zipkin:1.20 
tutum/dnsutils: latest 


这 些 镜 像 可 以 直接 通过 Docker Hub 获取 ， 我 将 它们 下 载 下 来 并 上 传 到 了 自己 的 私 
有 镜像 仓库 harbor-001.jimmysong.io 中 ， 下 文中 用 到 的 镜像 恬 来 自我 的 私有 
镜像 仓库 ，yaml 配置 见 linkerd 目录 ， 并 在 使 用 时 将 配置 中 的 镜像 地 址 修改 为 你 自 
己 的 。 


at 

首先 需要 先 创 建 RBAC， 因 为 使 用 namerd 和 ingress 时 需要 用 到 。 
$ kubectl create -f linkerd-rbac-beta.yml 

Linkerd 提供 了 Jenkins 示例 ， 在 部 署 的 时 候 使 用 以 下 命令 : 


$ kubectl create -f jenkins-rbac-beta.yml 
$ kubectl create -f jenkins.yml 


访问 http://jenkins.jimmysong.io 


EW: 


€ Q OO jenkins.jimmysong.io/job/hello world/build?delay-Osec 7r¥/9O8U0R o * 








EA - Jenkins pipeline 





€ © QC f O jenkins jimmysong.io/job/hello world/configure */90«*925.0x 


@ Jenkins udi 


Jenkins hello. world 


General 


项 目 名 称 hello world 


描述 


[Plain text] 预览 
Do not allow concurrent builds 





e 
| 昌 的 构建 e 
参数 化 构建 过 程 e 

String Parameter EJ © 

名 字 gitRepo e 

默认 值 | ntips:/lgithub.comvlinkerd/linkerc-examples e 

描述 linkerd-examples repo to clone and build e 

[Plain text) Er "E 

String Parameter ES e 

名 字  giBranch e 

SAE master e 

描述 ^ — branch to build from linkerd-examples repo e 


图 片 - Jenkins config 


注意 : 要 访问 Jenkins 需要 在 Ingress 中 增加 配置 ， 下 文 会 提 到 。 


在 kubernetes 中 使 用 Jenkins 的 时 候 需 要 注意 Pipeline 中 的 配置 


def currentVersion = getCurrentVersion() 

def newVersion = getNextVersion(currentVersion) 

def frontendIp = kubectl("get svc 15d -o jsonpath=\"{.status 
. loadBalancer.ingress[0].*}\"").trim() 

def originalDst = getDst(getDtab()) 


frontendIP 的 地 址 要 配置 成 service 的 Cluster IP ， 因 为 我 们 没有 用 到 
LoadBalancer ° 


需要 安装 namerd » namerd 负责 dtab 信息 的 存储 ， 当 然 也 可 以 存储 在 eted ` 
consul  » dtab 保存 的 是 路 由 规则 信息 ， 支 持 递 归 解 析 ， 详 见 dtab。 


流量 切换 主要 是 通过 diab 来 实现 的 ， 通 过 在 HTTP 请 求 的 header 中 增加 15d- 
dtab 和 Host 信息 可 以 对 流量 分 离 到 kubernetes 中 的 不 同 service 上 。 


遇 到 的 问题 


Failed with the following error(s) Error signal dtab is already marked as being 
deployed! 


Bi 
o 


因为 该 dtab entry 已 经 存在 ， 需 要 删除 后 再 i 


访问 http://namerd.jimmysong.io 


namerd admin x 


= Q (Y | © namerd.jimmysong.io/dtab/internal 


Namespace "internal" 


| /srv 
| host 
Ee 
| /sve 
| /host/world 


Edit 





图 片 - namerd 


dtab 保存 在 namerd 中 ， 该 页 面 中 的 更 改 不 会 生效 ， 需 要 使 用 命令 行 来 操作 。 


使 用 namerctl 来 操作 。 


$ namerctl --base-url http://namerd-backend.jimmysong.io dtab up 
date internal file 


注意 : update 时 需要 将 更 新 文本 先 写 入 文件 中 。 


3f Linkerd 


直接 使 用 yam 文件 部 署 ， 注 意 修 改 镜像 仓库 地 址 。 








# 创建 namerd 

$ kubectl create -f namerd.yaml 

# 创建 ingress 

$ kubectl create -f linkerd-ingress.yml 
# 创建 测试 服务 hello-world 

$ kubectl create -f hello-world.yml 

A 创建 API 服务 

$ kubectl create -f api.yml 

# 创建 测试 服务 world-v2 

$ kubectl create -f world-v2.yml 


为 了 在 本 地 调试 linkerd， 我 们 将 linkerd 的 service 加 入 到 ingress 中 ， 详 见 边缘 
节点 配置 。 


在 Ingress 中 增加 如 下 内 容 : 


- host: linkerd.jimmysong.io 


http: 
paths: 
- path: / 
backend: 


serviceName: 15d 
servicePort: 9990 
- host: linkerd-viz.jimmysong.io 


http: 
paths: 
- path: / 
backend: 


serviceName: linkerd-viz 
servicePort: 80 
- host: 15d.jimmysong.io 


http: 
paths: 
- path: / 
backend: 


serviceName: 15d 
servicePort: 4141 
- host: jenkins.jimmysong.io 


http: 
paths: 
- path: / 
backend: 


serviceName: jenkins 
servicePort: 80 


在 本 地 /etc/hosts 中 添加 如 下 内 容 : 


172.20.0.119 linkerd.jimmysong.io 
172.20.0.119 linkerd-viz.jimmysong.io 
172.20.0.119 15d.jimmysong.io 


测试 路 由 功能 
使 用 curl 简单 测试 。 
单条 测试 


$ curl -s -H "Host: www.hello.world" 172.20.0.120:4141 
Hello (172.30.60.14) world (172.30.71.19)! !96 


请 注意 请 求 返回 的 结果 ， 表 示 访 问 的 是 world-v1 service ° 


$ for i in $(seq 0 10000);do echo $i;curl -s -H "Host: www.hello 
.world" 172.20.0.120:4141; done 


使 用 ab test ° 


$ ab -c 4 -n 10000 -H "Host: www.hello.world" http://172.20.0.1 
20:4141/ 

This is ApacheBench, Version 2.3 «$Revision: 1757674 $> 
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeust 
ech.net/ 

Licensed to The Apache Software Foundation, http://www.apache.or 
g/ 


Benchmarking 172.20.0.120 (be patient) 
Completed 1000 requests 
Completed 2000 requests 
Completed 3000 requests 
Completed 4000 requests 
Completed 5000 requests 
Completed 6000 requests 
Completed 7000 requests 
Completed 8000 requests 
Completed 9000 requests 
Completed 10000 requests 
Finished 10000 requests 


Server Software: 
Server Hostname: 172.20.0.120 
Server Port: 4141 


Document Path: / 


Document Length: 43 bytes 

Concurrency Level: 4 

Time taken for tests: 262.505 seconds 

Complete requests: 10000 

Failed requests: 0 

Total transferred: 2210000 bytes 

HTML transferred: 430000 bytes 

Requests per second: 38.09 [#/sec] (mean) 

Time per request: 105.002 [ms] (mean) 

Time per request: 26.250 [ms] (mean, across all concurrent 
requests) 

Transfer rate: 8.22 [Kbytes/sec] received 


Connection Times (ms) 
min mean[+/-sd] median max 


Connect: 36 51 91.1 39 2122 
Processing: 39 54 29.3 46 585 
Waiting: 39 52 20.3 46 362 
Total: 76 105 96.3 88 2216 


Percentage of the requests served within a certain time (ms) 


50% 88 
66% 93 
75% 99 
80% 103 
90% 119 
95% 146 
98% 253 
99% 397 


100% 2216 (longest request) 


监控 kubernets 中 的 服务 与 实例 
访问 http://linkerd.jimmysong.io 查看 流量 情况 


Outcoming 


o BS linkerd admin x Jimmy. 


G CŒ £t © linkerd.jimmysong.io, 





LI 


router Pending Fail rate 


outgoing 


Retry budget available: 20% / 20% 


cuents 
io.I5d.k8s/default/http/world-vi 


Failures Latencies 
| max 
| pose 
Requests Connections 


3 


Endpoints available: 3/3 


0.0.0.0/4140 
Latencies 
Ira 
lo 


Requests 


3 


memory used 1122MB 





图 片 linkerd 3 4€ 


Incoming 


o BS linkerd admin x Jimmy. 
€ C ( O lnkerd.immysong.io arl Soa y x 
AN inkerd 


m « nettes Fail rate 
incoming 0 


Retry budget available: 20% / 20% 


[#/i0.15d.k8s/default/http/world-vi 


Failures 


Requests ections 


Endpoints available: 1 / 1 


0.0.0.0/4141 


-49 iso 


Requests. Connections 


-49 





图 片 - linkerd 监 控 


访问 http://linkerd-viz.jimmysong.io 查看 应 用 metric 监控 


(9 - 器 linkerd-viz- 必 < ZoomOut > OLast 5 minutes Refresh every 5s 


incoming ~ Œ linkerd.io 


linkerd enables 
Need help? Join us on 


N$ linkerd 


Services Monitored linkerd Instances Global Success Rate Global Request Volume 4XX Errors 


a 3 Orps Orps 


TOP LINE 


Success Rates Request Volumes 


SERVICE METRICS 


PSS dispatcher 


Success Rate Request Volume 


Success Rate Request Volume 


Success Rate Request Volume 





PER-INSTANCE METRICS 


Success Rate Request Volume 
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+ADD ROW 





测试 路 由 
测试 在 http header 中 增加 dtab 规则 。 


$ curl -H "Host: www.hello.world" -H "l15d-dtab:/host/world => /s 
rv/world-v2;" 172.20.0.120:4141 
Hello (172.30.60.14) earth (172.30.94.40)!! 


请 注意 调用 返回 的 结果 ， 表 示 调 用 的 是 world-v2 4% service ° 
另外 再 对 比 ab test 的 结果 与 linkerd-viz 页 面 上 的 结果 ， 可 以 看 到 结果 一 致 。 


但 是 我 们 可 能 不 想 把 该 功能 暴露 给 所 有 人 ， 所 以 可 以 在 前 端 部 署 一 个 nginx 来 过 滤 
header 中 的 15d-dtab 打头 的 字段 ， 并 通过 设置 cookie 的 方式 来 替代 header 里 
的 15d-dtab 字段 。 


$ http_proxy=http://172.20.0.120:4141 curl -s http:/hello 
Hello (172.30.60.14) world (172.30.71.19)!! 
将 Linkerd 1t > Ingress controller 


将 Linkerd 作为 kubernetes ingress controller 的 方式 跟 将 Treafik 作为 ingress 
controller 的 过 程 过 程 完全 一 样 ， 可 以 直接 参考 边缘 节点 配置 。 


架构 如 下 图 所 示 9 


Linkerd 使 用 指南 


External Traffic 


DaemonSet 15d” : 


Ingress "hello-world" 





Replication Controller “world” I Replication Controller ^world-v2" : 


& - Linkerd ingress controller 


(BA X 8 A Service Mesh for Kubernetes - Buoyant.io) 





当然 可 以 绕 过 kubernetes ingress controller 直接 使 用 linkerd 作为 边界 路 由 ， 通 过 


dtab 和 linkerd 前 面 的 nginx 来 路 由 流量 。 


参考 


e https://github.com/linkerd/linkerd-examples 
e A Service Mesh for Kubernetes 
e dtab 
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Conduit - T Kubernetes $5 42 = Zt Service 
Mesh 


2017 年 12 月 在 得 克 萨 斯 州 的 Asdin，KubeCon 和 CloudNativeCon 上， 创造 了 
Service Mesh 这 个 词汇 并 开源 了 Linkerd 的 公司 Buoyant， 又 开源 了 一 款 针 对 
Kubernetes 的 超 轻 量 Service Sesh 一 一 Conduit。 它 可 以 透明 得 管理 服务 运行 时 之 
间 的 通信 ， 使 得 在 Kubernetes 上 运行 服务 更 加 安全 和 可 靠 ; 它 还 具有 不 用 修改 任何 
应 用 程序 代码 即 可 改进 应 用 程序 的 可 观测 性 、 可 靠 性 及 安全 性 等 方面 的 特性 。 


Condiut 与 Linkerd 的 设计 方式 不 同 ， 它 跟 |stio 一 样 使 用 的 是 Sidecar 模 式 ， 但 架构 又 
没 lstio 那 么 复杂 。Conduit 只 支持 Kubernetes， 且 只 支持 HTTP2 (包括 gRPC) W 
议 。 


Conduit 使 用 Rust 和 Go 语言 开发 ，GitHub 地 址 https://github.com/runconduit/conduit 


安装 Conduit 必 须 使 用 Kubernetes1.8 以 上 版 本 。 


考 


Conduit GitHub : https://github.com/runconduit/conduit 


关于 Conduit 的 更 多 资源 请 参考 官方 网 站 : https://conduit.io/ 
另外 ， 我 们 翻译 Conduit 的 官方 文档 见 : https://github.com/doczhen/conduit 


关于 Service Mesh 的 更 多 内 容 请 访问 Service Mesh 中 
: http:/Awww.servicemesh.cn/ 
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Conduit 概览 


Conduit —  # *t Kubernetes 4) 38 42 & 48 f service mesh。 它 可 以 透明 得 管理 服 
务 运 行 时 之 间 的 通信 ， 使 得 在 Kubernetes 上 运行 服务 更 加 安全 和 可 靠 ; 它 还 具有 不 
用 修改 任何 应 用 程序 代码 即 可 改进 应 用 程序 的 可 观测 性 、 可 靠 性 及 安全 性 等 方面 的 
特性 。 


本 文档 将 从 一 个 较 高 层次 介绍 Conduit 及 其 是 如 何 工 作 的 。 如 果 不 熟 悉 service mesh 
模型 ， 或 许可 以 先 阅读 Wiliam Morgan 的 概览 文章 什么 是 service mesh ? 为 什么 需 
要 它 ? 


Conduit 架 构 


Conduit service mesh 部 署 到 Kubernetes 集 群 时 有 两 个 基本 组 件 : 数据 平面 和 控制 
平面 。 数 据 平 面 承 载 服 务实 例 间 实际 的 应 用 请 求 流量 ， 而 控制 平面 则 驱动 数据 平面 
并 修改 其 行为 (及 访问 聚合 指标 ) 提供 API。Conduit CLI 和 Web UI 使 用 此 API 并 为 

人 类 提供 符合 人 体 工 程 学 的 控制 。 

让 我 们 依次 认识 这 些 组 件 。 

Conduit 的 数据 平面 由 轻 量 级 的 代理 组 成 ， 这 些 代理 作为 sidecar 容 器 与 每 个 服务 代 

码 的 实例 部 署 在 一 起 。 如 果 将 服务 “添加 ”到 Conduit servie mesh 中 ， 必 须 重 新 部 署 

该 服务 的 pod， 以 便 在 每 个 pod 中 包含 一 个 数据 平面 代理 。( conduit inject 命 
令 可 以 完成 这 个 任务 ， 以 及 透明 地 从 每 个 实例 通过 代理 汇集 流量 所 需 的 配置 工 

作 。) 

这 些 代理 透明 地 拦截 进出 每 个 pod 的 通信 ， 并 增加 诸如 重 试 和 超时 、 检 测 及 加 蜜 
(TLS) 等 特性 ， 并 根据 相关 策略 来 允许 和 拒绝 请 求 。 

这 些 代理 并 未 设计 成 通过 手动 方式 配置 ; 相反 ， 它 们 的 行为 是 由 控制 平面 驱动 的 。 


Conduit 控 制 平 面 是 一 组 运行 在 专用 Kubernetes 名 称 空间 (默认 情况 下 
A conduit ) 的 服务 。 这 些 服 务 完成 各 种 事情 - 聚合 遥测 数据 ， 提 供 面 向 用 户 的 
API， 向 数据 平面 代理 提供 控制 数据 等 。 它 们 一 起 驱动 数据 平面 的 行为 。 


使 用 Conduit 


为 了 支持 Conduit 的 人 机 交互 ， 可 以 使 用 Conduit CLE web UI (也 可 以 通过 相关 工 
具 比 如 kubectl ) ° CLI 和 web UI 通过 API| 了 驱动 控制 平面 ， 而 控制 平面 相应 地 了 驱 
动 数据 平面 的 行为 。 


控制 平面 API 设 计 得 足够 通用 ， 以 便 能 基于 此 构建 其 他 工具 。 上 比如 ， 你 可 能 希望 从 
另外 一 个 CUVCD 系 统 来 驱动 API 。 


运行 conduit --help 可 查看 关于 CLI 功 能 的 简短 概述 。 


Conduit 与 Kubernetes 


Conduit 设 计 用 于 无 颖 地 融入 现 有 的 Kubernetes 系 统 。 该 设计 有 几 个 重要 特征 。 


第 一 ，Conduit CLI ( conduit ) 设计 成 尽 可 能 地 与 kubect1 一 起 使 用 。 比 
如 ， conduit install 和 conduit inject 生成 的 Kubernetes 配 置 ， 被 设计 
成 直接 送 入 kubectl 。 这 是 为 了 在 service mesh 和 编排 系统 之 间 提 供 一 个 明确 的 
分 工 ， 并 且 使 得 Conduit 适 配 现 有 的 Kubernetes 工 作 流 程 。 


第 二 ，Kubernetes 中 Conduit 的 核心 词 是 Deployment， 而 不 是 Service。 举 个 例 

F> conduit inject 增加 一 个 Deployment，Conduit web UI 会 显示 这 些 
Deployment， 并 且 每 个 Deployment 都 会 给 出 聚合 的 性 能 指标 。 这 是 因为 单个 pod 可 
以 是 任意 数量 Service 的 一 部 分 ， 而 这 会 导致 流量 与 pod 之 间 出 现 复 杂 的 映射 。 相 比 
之 下 ，Deployment 要 求 单 个 pod 只 能 属于 一 个 Deployment 的 一 部 分 。 通 过 基于 
Deployment 而 不 是 Service 来 构建 ， 流 量 与 pod 间 的 映射 就 总 是 清晰 的 。 


这 两 个 设计 特性 能 很 好 地 组 合 。 比 如 ， conduit inject 可 用 于 一 个 运行 的 
Deployment， 因 为 当 它 更 新 Deployment 时 ，Kubernetes 会 回 滚 pod 以 包括 数据 平 
面 代理 。 


扩展 Conduit 的 行为 


Conduit 控 制 平面 还 为 构建 自 定义 功能 提供 了 一 个 便捷 的 入 口 。Conduit 最 初 发 布 时 
并 不 支持 这 一 点 ， 在 不 远 的 将 来 ， 通 过 编写 gRPC 插 件 来 作为 控制 平面 的 一 部 分 运 
行 ， 将 能 扩展 Conduit 的 功能 ， 而 无 需 重新 编译 Conduit。 
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zc X Conduit 


本 文档 指导 您 如 何在 kubernetes 上 安装 Conduit service mesh ° 


前 提 条 件 


e kubernetes 版 本 为 1.8 或 以 上 
用 到 的 镜像 如 下 


e buoyantio/kubectl:v1.6.2 

e gcr.io/runconduit/controller:v0.1.0 
e gcr.io/runconduit/web:v0.1.0 

e prom/prometheus:v1.8.1 


其 中 位 于 gcr.io 的 镜像 我 备份 到 了 DockerHub : 


e jimmysong/runconduit-web:vO.1.0 
e jimmysong/runconduit-controller:v0.1.0 


另外 两 个 镜像 本 身 就 可 以 从 DockerHub 上 下 载 。 


oh 
到 release 页 面 上 下 载 conduit 的 二 进 制 文件 。 


使 用 conduit install 命令 生成 了 用 于 部 署 到 kubernetes 中 yaml 文 件 ， 然 后 修改 
文件 中 的 镜像 仓库 地 址 为 你 自己 的 镜像 地 址 。 


conduit nota LTA CONUL 0.1.0.yaml 
HANG PX R t XE 410 


Kubect i. anu -f conduit-0.1.0.yaml 


修改 后 的 yaml 文 件 见 : conduit-0.1.0.yaml » 


注意 : Conduit 官 方 给 出 的 yaml 文 件 中 不 包括 RBAC 授 权 ， 我 重新 修改 了 ， 增 加 了 
RBAC 和 ServiceAccount 。 


使 用 kubectl proxy 来 开放 外 网 访问 conduit dashboard : 


kubectl proxy --address='172.20.0.113' --port=8001 --accept-hosts 
STNG 


E mum id 














在 浏览 器 中 访问 
http://172.20.0.113:8001/api/v1/namespaces/conduit/services/web:http/proxy/servi 
cemesh 将 看 到 如 下 页 面 : 


€ Q (y | © 172.20.0.113:8001/api/v1i/namespaces/conduit/services/web:http/proxy/servicemesh & *|9 O* AROA Oo: 


CONDUIT Service mesh overview 


The service mesh was successfully installed 


Service mesh 
© Controller successfully installed © 1deployments detected O Connect your first deployment 


Deployments 


Add one or more deployments to the deployment.yml file 
Routes 
Then run conduit inject deployment.yml | kubectl apply -f - toadd deploys to the service mesh 


Docs 





CONTROL PLANE Components SERVICE MESH DETAILS 
NAME VALUE 
DEPLOYMENT PODS PODSTATUS 
v0.1.0 
Controller destination 
mponent: 
Controller proxy-api 
Added deployment: 0 
Controller public-api 
Unadded deployment 0 
Controller t 
Data plane pro 0 
Controller t: try 
F nethe 
Web UI 0 
All deployments have been added to 
DATA PLANE Deployments Proxies the service mesh. 
DEPLOYMENT PODS PROXY STATUS 





图 片 - Conduit dashboard 


Conduit inject 


Conduit 注 入 的 时 候 需 要 用 到 如 下 两 个 镜像 : 


e gcr.io/runconduit/proxy:v0.1.0 
e gcr.io/runconduit/proxy-init:vO. 1.0 


我 将 其 备份 到 了 DockerHub : 


e jimmysong/runconduit-proxy:v0.1.0 
e jimmysong/runconduit-proxy-init:v0.1.0 


查看 conduit 向 yaml 文 件 中 注入 了 哪些 配置 ， 我 们 使 用 my-nginx.yam| 为 例 : 


conduit inject --init-image harbor-001.jimmysong.io/library/runc 
onduit-proxy-init --proxy-image harbor-001.jimmysong.io/library/ 
runconduit-proxy my-nginx.yaml|kubectl apply -f - 


注意 : 只 需要 指定 镜像 名 称 即 可 ，tag 与 使 用 的 conduit server 版 本 相同 ， 会 自动 注 
Ao 


my-nginx.yaml 4$ A Ze T : 


apiVersion: extensions/vibeta1 
kind: Deployment 
metadata: 

name: my-nginx 
spec: 

replicas: 2 

template: 

metadata: 

labels: 
run: my-nginx 

spec: 

containers: 

- name: my-nginx 
image: harbor-001.jimmysong.io/library/nginx:1.9 
ports: 

- containerPort: 80 
apiVersion: vi 
kind: Service 
metadata: 

name: my-nginx 

labels: 
app: my-nginx 
spec: 

ports: 

- port: 80 
protocol: TCP 
name: http 

selector: 
run: my-nginx 


Conduit 自 动 注入 后 生成 的 新 的 yaml 文 件 内 容 如 下 : 


apiVersion: extensions/vibeta1 
kind: Deployment 
metadata: 
creationTimestamp: null 
name: my-nginx 
spec: 
replicas: 2 
strategy: {} 
template: 
metadata: 
annotations: 
conduit.io/created-by: conduit/cli v0.1.0 
conduit.io/proxy-version: v0.1.0 
creationTimestamp: null 
labels: 
conduit.io/controller: conduit 
conduit.io/plane: data 
run: my-nginx 
spec: 
containers: 
- image: harbor-001.jimmysong.io/library/nginx:1.9 
name: my-nginx 
ports: 
- containerPort: 80 
resources: {} 
- env: 
- name: CONDUIT PROXY LOG 
value: trace,h2=debug, mio=info, tokio_core=info 
- name: CONDUIT_PROXY_CONTROL_URL 
value: tcp://proxy-api.conduit.svc.cluster.local: 8086 
- name: CONDUIT_PROXY_CONTROL_LISTENER 
value: tcp://0.0.0.0:4190 
- name: CONDUIT_PROXY_PRIVATE_LISTENER 
value: tcp://127.0.0.1:4140 
- name: CONDUIT_PROXY_PUBLIC_LISTENER 
value: tcp://0.0.0.0:4143 
- name: CONDUIT_PROXY_NODE_NAME 
valueFrom: 
fieldRef : 
fieldPath: spec.nodeName 
- name: CONDUIT_PROXY_POD_NAME 
valueFrom: 
fieldRef: 
fieldPath: metadata.name 
- name: CONDUIT PROXY POD NAMESPACE 
valueFrom: 
fieldRef: 
fieldPath: metadata.namespace 
image: harbor-001.jimmysong.io/library/runconduit-proxy: 
v0.1.0 
imagePullPolicy: IfNotPresent 
name: conduit-proxy 


ports: 
- containerPort: 4143 
name: conduit-proxy 
resources: {} 
securityContext: 
runAsUser: 2102 
initContainers: 
- args: 
- -P 
"4143" 
- -0 
_ "4140" 
- -i 
= "4190" 
- -u 
_ "2102" 
image: harbor-001.jimmysong.io/library/runconduit-proxy- 
init:v0.1.0 
imagePullPolicy: IfNotPresent 
name: conduit-init 
resources: {} 
securityContext: 
capabilities: 
add: 
- NET ADMIN 
privileged: false 
status: {} 
apiVersion: vi 
kind: Service 
metadata: 
name: my-nginx 
labels: 
app: my-nginx 
spec: 
ports: 
- port: 80 
protocol: TCP 
name: http 
selector: 
run: my-nginx 


x 


部 署 示例 应 用 


使 用 下 面 的 命令 部 署 官方 提供 的 示例 应 用 : 


curl https://raw.githubusercontent.com/rootsongjc/kubernetes-han 
dbook/master/manifests/conduit/emojivoto.yml | conduit inject -- 
init-image harbor-001.jimmysong.io/library/runconduit-proxy-init 

--proxy-image harbor-001.jimmysong.io/library/runconduit-proxy 
- --skip-inbound-ports-80 | kubectl apply -f - 


注意 : 其 中 使 用 的 镜像 地 址 已 经 改 为 我 的 私有 镜像 仓库 地 址 ， 大 家 使 用 时 请 注意 修 
改 。 


参考 


e Getting started - conduit.io 
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Envoy 


Envoy 是 一 款 由 Lyft 开源 的 ， 使 用 C++ 编写 的 L7 代理 和 通信 总线， 目前 是 CNCF 
旗下 的 开源 项 目 ， 代 码 托 管 在 GitHub 上 ， 它 也 是 Istio service mesh 中 默认 的 
data plane ° 


特性 


Envoy 包括 如 下 特性 : 


e 进程 外 架构 ， 不 侵入 应 用 进程 
e 使 用 现代 版 C++11 代码 
e L3/L4 filter 架构 

e HTTP L7 filter 架构 

e 支持 HTTP/2 

e HTTP L7 routing 

e 支持 gRPC 

e 支持 MongoDB L7 

e 动态 配置 

e 最 住 可 观测 性 

e 支持 front/edge proxy 
e 高 级 负载 均衡 

e 健康 检查 

e 服务 发 现 

e 支持 DynamoDB L7 


Envoy 本 身 无 法 构成 一 个 完整 的 Service Mesh， 但 是 它 可 以 作为 service mesh 中 
的 应 用 间 流 量 的 代理 ， 负 责 service mesh 中 的 数据 层 。 


负载 均衡 与 代理 


在 Matt Klein (Envoy 的 作者 ) 的 Introduction to modern network load balancing 
and proxying 文章 详细 描述 了 现代 的 网 络 负载 均衡 与 代理 的 特性 与 模式 ，L4 与 L7 
负载 均衡 的 区 别 以 及 L7 负载 均衡 的 现状 ， 总 结 如 下 图 。 


Envoy 


static configuration file 
DNS 
Service discovery 
Zookeeper/etcd/Consul... 
Envoy's universal data plane API 
active 
Health checking 
passive 
random 
round robin 
Load balancing Load balancing algorithms weight robin 


weight robin 


Features 


least connections 


Sticky sessions 





| Load Balancer 


TLS termination 





Observability 


Security and Dos mitigation 


Configuration and control plane 


middle proxy 


edge proxy always required 


Topology types 


embedded client library 


source https:/fimmysong.io sidecar proxy the future of service-to-serivce communication 


图 片 - 负载 均衡 器 的 特性 以 及 拓扑 类 型 


Matt Klein 是 在 他 的 文章 中 指出 sidecar 模式 的 proxy 将 取代 另外 三 种 模式 而 成 为 
服务 间 通 信 的 负载 均衡 器 。 


e Introduction to modern network load balancing and proxying 
e 更 多 信息 请 参考 Envoy 官网 。 
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Envoy 的 架构 与 基本 术语 


在 了 解 一 ee 
能 理解 这 门 技术 。 本 文 将 为 大 家 介绍 Envoy 中 的 基本 术语 和 重点 概念 。 


RH 


下 图 是 Envoy je 的 架构 图 ， 显 示 了 host B 经 过 Envoy 访问 host A HH » & 
个 host 上 都 可 能 运行 多 个 service，Envoy 中 也 可 能 有 多 个 Listener， 每 个 
Listener 中 可 外 oe ^* filter 组 成 了 chain ° 





Envoy Proxy Architecture Diagram 
receive request 
https://www.envoyproxy.io/docs/envoy/latest/ 


vO. 1 















Listener 





Cluster Discovery Service l 
Endpoint Discovery Service 


Service Discovery Service | 








upstream 























downstream 


HTTP router filter 
Listener Discovery Service i health checking 


| 


host B 


Route Discovery Service | 
































send request 








source https://jimmysong.io 








E HA - Envoy proxy 架构 图 


其 中 的 基本 术语 将 在 下 面 解 释 。 


基本 术语 


Host: 能 够 进行 网 络 通信 的 实体 〈 在 手机 或 服务 器 等 上 的 应 用 程序 ) 。 在 Envoy 
中 主机 是 指 逻 辑 网 络 应 用 程序 。 只 要 每 台 主 机 都 可 以 独立 寻 址 ， 一 块 物理 硬件 上 就 
运行 多 个 主机 。 


Downstream : 下 游 (downstream) 主机 连接 到 Envoy， 发 送 请 求 并 或 获得 响 


Upstream : 上 游 (upstream) 主机 获取 来 自 Envoy 的 链接 请 求 和 响应 。 


Cluster: 集群 (cluster) Æ Envoy 连接 到 的 一 组 逻辑 上 相似 的 上 游 主 机 。Envoy Ñ 
过 服务 发 现 发 现 集 群 中 的 成 员 。Envoy 可 以 通过 主动 运行 状况 检查 来 确定 集群 成 员 
的 健康 状况 。Envoy 如 何 将 请 求 路 由 到 集群 成 员 由 负载 均衡 策略 确定 。 


Mesh : 一 组 互相 协调 以 提供 一 致 网 络 拓扑 的 主机 。Envoy mesh 是 指 一 组 Envoy 
代理 ， 它 们 构成 了 由 多 种 不 同 服务 和 应 用 程序 平台 组 成 的 分 布 式 系统 的 消息 传递 基 
础 。 


运行 时 配置 : 与 Envoy es 系统 。 可 以 在 无 需 重 启 Envoy X 
更 改 Envoy 主 配置 的 情况 下 ， 通 过 更 改 设置 来 影响 操作 。 


Listener: 侦 听 器 (listener) 是 可 以 由 下 游客 户 端 连接 的 命名 网 络 位 置 (例如 ， 端 
口 、unix 域 套 接 字 等 ) 。Envoy 公开 一 个 或 多 个 下 游 主机 连接 的 侦 听 器 。 一 般 是 每 
台 主 机 运行 一 个 Envoy， 使 用 单 进程 运行 ， 但 是 每 个 进程 中 可 以 启动 任意 数量 的 
Listener (监听 器 ) ， 目 前 只 监听 TOP ， SUE 都 独立 配置 一 定数 量 的 
(L3/LA) 网 络 过 滤器 。Listenter 也 可 以 通过 Listener Discovery Service (LDS) 
动态 获取 。 


Listener filter : Listener 使 用 listener filter (监听 器 过 滤器 ) 来 操作 链接 的 元 数 
据 。 它 的 作用 是 在 不 更 改 Envoy 的 核心 功能 的 情况 下 添加 更 多 的 集成 功能 。 
Listener filter 的 API 相对 简单 ， 因 为 这 些 过 滤器 最 终 是 在 新 接受 的 套 接 字 上 运行 。 
ESTY LR HR 支持 更 复杂 的 场景 ， 例 如 调用 速率 限制 。Envoy 已 经 包含 了 


个 监听 器 过 xc o 


Http Route Table : HTTP 的 路 由 规则 ， 例 如 请 求 的 域名 ，Path 符合 什么 规则 ， 转 
发 给 哪个 Cluster ° 


Health checking : oe nt o 但是， 即使 使 用 其 他 服 
务 发 现 方式 ， 也 有 相应 需要 进行 主动 健康 检查 的 情况 。 详 见 health checking ° 


xDS 


XDS 是 一 个 关键 概念 ， 它 是 一 类 发 现 服务 的 统称 ， 其 包括 如 下 几 类 : 


e CDS : Cluster Discovery Service 
e EDS : Endpoint Discovery Service 
e SDS : Service Discovery Service 
e RDS : Route Discovery Service 

e LDS : Listener Discovery Service 


正 是 通过 对 xDS 的 请 求 来 动态 更 新 Envoy 配置 。 


Envoy Mesh 


Envoy Mesh 指 的 是 由 envoy 做 负载 均衡 和 代理 的 mesh。 该 Mesh 中 会 包含 两 类 
envoy : 


e Edge envoy : 即 流量 进出 mesh 时 候 的 envoy > 48 2$ -F kubernetes 中 的 
ingress ° 

e Service envoy : 服务 envoy 是 跟 每 个 serivce 实例 一 起 运行 的 ， 应 用 程序 无 
知 的 进程 外 工具 ， 在 kubernetes 中 会 与 应 用 容器 以 sidecar 形式 运行 在 同一 个 
pod 中 。 


Envoy 即 可 以 单独 作为 edge envoy， 也 可 以 仅 做 service envoy 使 用 ， 也 可 以 两 者 
同时 使 用 。Mesh 中 的 所 有 envoy 会 共享 路 由 信息 。 


Envoy 配置 


Envoy 中 的 配置 包括 两 大 类 : listenner 配置 和 cluster 配置 。 


Listener 配置 


我 们 知道 Envoy 中 可 以 配置 一 组 listener 以 SML Ru o Listener 中 设置 
监听 的 TCP 端口 ， 还 有 一 组 filter 对 这 些 端 口上 的 数据 流 进行 处 理 。 如 下 所 示 ， 该 
示例 来 自 使 用 Envoy 作为 前 端 代理 。 


listeners: 
- address: 
socket_address: 
address: 0.0.0.0 
port_value: 80 
filter chains: 
- filters: 
- name: envoy.http connection manager 
config: 
codec type: auto 
stat prefix: ingress http 
route config: 
name: local route 
virtual hosts: 
- name: backend 
domains: 
Wwe 
routes: 
- match: 
prefix: "/service/1" 
route: 
cluster: service1 
- match: 
prefix: "/service/2" 
route: 
cluster: service2 


这 是 一 个 http connection manager 例子 ， 其 中 必须 包含 virtual hosts 


是 
配置 ， 而 virtual hosts 配置 中 必须 包含 以 下 几 项 配置 : 


e name :服务 名 称 
e domains : DNS 域名 ， 必 须 能 跟 virtual host 的 URL 匹配 
e routes :路 由 列表 


每 个 路 由 中 还 可 以 包含 以 下 配置 : 


e prefix : URL 路径 前 组 
e cluster : 处 理 该 请 求 的 envoy cluster 
e timeout ms : 当 出 错时 的 超时 时 间 


如 上 面 的 例子 中 ， 我 们 还 需要 定义 servicel cluster 和 service2 cluster ° 


Cluster 配置 


Cluster 是 一 组 逻辑 相似 的 主机 配置 ， 定 义 哪 些 主机 属于 一 个 服务 ，cluster 的 配置 
中 包含 了 服务 发 现 和 负载 均衡 方式 配置 。 依 然 是 参考 使 用 Envoy 作为 前 端 代 理 中 的 
配置 : 


clusters: 
- name: servicel 
connect timeout: 0.25s 
type: strict dns 
lb policy: round robin 
http2 protocol options: {} 
hosts: 
- SOcket address: 
address: service1 
port value: 80 
- name: service2 
connect timeout: 0.25s 
type: strict dns 
lb policy: round robin 
http2 protocol options: {} 
hosts: 
- SOcket address: 
address: service2 
port value: 80 


Cluster 的 配置 中 至 少 包含 以 下 信息 : 


e name ‘cluster 名 称 ， 就 是 服务 名 称 
e type :该 cluster 怎么 知道 主机 是 否 局 动 ? 即 服务 发 现 类 型 ， 有 以 下 方式 : 
o static : 监听 cluster 中 的 所 有 主机 
o strict dns : envoy 会 监听 DNS， 每 个 匹配 的 A 记录 都 会 认定 为 有 效 
o logical_dns : envoy 将 使 用 DNS 来 增加 主机 ， 如 果 DNS 不 再 返回 该 
主机 也 不 会 删除 这 些 主 机 信息 
o sds : BP Serivce Discovery Serivce，envoy 访问 外 部 的 REST 获取 
cluster 成 员 信 息 
e lb type : cluster 的 负载 均衡 类 型 ， 有 以 下 方式 : 
o round robin : 轮 询 主机 
o weighted least request : 最 近 获 得 最 少 请 求 的 主机 
o random : 随机 
e hosts : 能 够 定义 cluster 中 主机 的 URL 地 址 ， 通 常 是 tcp:// URL 


[一 LL >i PE Hx } D oog 


e Terminology - www.envoyproxy.io 
e Part 1: Getting started with Envoy Proxy for microservices resilience 
e Envoy 作 为 前 端 代 理 
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本 文 是 使 用 Envoy 作为 前 端 代 理 的 介绍 ， 仅 使 用 docker 容器 和 docker-compose 
做 编排 在 单机 中 运行 ， 帮 助 我 们 从 更 底层 了 解 Envoy， 当 我 们 将 Envoy 作为 Istio 
Service Mesh 的 data panel 的 时 候 将 更 加 游刃有余 。 


快速 开始 


Envoy 中 的 所 有 规则 配置 跟 Kubernetes 一 样 都 是 通过 YAML 文件 来 完成 的 。 在 继 
续 下 面 的 步骤 之 前 ， 首 先 克 隆 Envoy 的 GitHub repo ° 


git clone https://github.com/envoyproxy/envoy.git 


运行 sandbox 测试 
Envoy 官方 提供 了 以 下 打包 用 例 : 


e Front Proxy 

e Zipkin Tracing 
e Jaeger Tracing 
e gRPC Bridge 


全 部 可 以 使 用 docker-compose 运行 ， 代 码 可 以 在 
https://github.com/envoyproxy/envoy/tree/master/examples 找到 。 


Front proxy 


Envoy 在 envoymesh 的 边缘 做 反 向 代理 ， 详 细 使 用 方式 见 
https://www.envoyproxy.io/docs/envoy/latest/start/sandboxes/front_proxy， 在 此 我 
将 解说 下 以 下 问题 : 

e Envoy 是 如 何 作为 进程 外 架构 运行 的 ? 

e 为 何 说 Envoy 是 无 侵入 式 架构 ? 

e Envoy 作为 边缘 反 向 代理 能 做 什么 ? 


本 示例 的 架构 图 如 下 所 示 ， 此 时 Envoy 将 作为 一 个 反 向 代理 ， 类 似 于 Nginx’ 124 
Nginx 不 同 的 是 它 还 会 作为 一 个 进程 ， 伴 随 每 个 服务 一 起 运行 在 同一 个 容器 中 (在 
Kubernetes 中 可 以 作为 Sidecar 与 应 用 容器 一 起 运行 在 同一 个 Pod 中 ) 。 
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图 片 - Front proxy 部 署 结构 图 (转自 
https:/Wwww.envoyproxy.io/docs/envoy/latest/start/sandboxes/front_proxy ) 


在 此 示例 中 一 共有 3 个 服务 ， 我 们 需要 为 其 创建 容器 编排 的 ”docker- 
compose.yml 文件 。 


version: '2' 
services: 


front-envoy: 
build: 
context: 
dockerfile: Dockerfile-frontenvoy 
volumes: 
- ./front-envoy.yaml:/etc/front-envoy.yaml 
networks: 
- envoymesh 
expose: 
" 80 "n 
" 8001" 
ports: 
"8000:80" 
"8001:8001" 


servicel1: 
build: 
context: 
dockerfile: Dockerfile-service 
volumes: 
- ./service-envoy.yaml:/etc/service-envoy.yaml 
networks: 
envoymesh: 
aliases: 
- serviced 
environment: 
- SERVICE_NAME=1 
expose: 
_ "gg" 


service2: 
build: 
context: 
dockerfile: Dockerfile-service 
volumes: 
- ./service-envoy.yaml:/etc/service-envoy.yaml 
networks: 
envoymesh: 
aliases: 
- service2 
environment: 
- SERVICE_NAME=2 
expose: 
Z "gg" 


networks: 
envoymesh: {} 


使 用 docker-compose 启动 可 以 保证 三 个 服务 都 在 同一 个 网 络 内 ， 即 


frontproxy_envoymesh 网 络 中 。 


其 中 front-envoy 是 前 端 (边缘 ) Envoy 服务 ， 用 来 做 反 向 代理 ， 它 使 用 的 是 
Dockerfile-frontenvoy 文件 来 构建 镜像 的 ， 我 们 来 看 下 该 Dockerfile 的 


FROM envoyproxy/envoy: latest 


RUN apt-get update && apt-get -q install -y \ 
curl 


CMD /usr/local/bin/envoy -c /etc/front-envoy.yaml --service-clus 


ter front-proxy 


其 中 /etc/front-envoy.yaml 是 本 地 的 front-envoy.yaml 
们 看 下 该 文件 的 内 容 。 


static_resources: 
listeners: 
- address: 
socket_address: 
address: 0.0.0.0 
port_value: 80 
filter chains: 
- filters: 
- name: envoy.http connection manager 
config: 
codec type: auto 
stat prefix: ingress http 
route config: 
name: local route 
virtual hosts: 
- name: backend 
domains: 
.oHnx*xM 
routes: 
- match: 
prefix: "/service/1" 
route: 
cluster: service1 
- match: 
prefix: "/service/2" 
route: 
cluster: service2 
http filters: 
- name: envoy.router 
config: 4j 
clusters: 


挂 载 进去 的 。 我 


- name: servicel 
connect timeout: 0.25s 
type: strict dns 
lb policy: round robin 
http2 protocol options: {} 
hosts: 
- SOcket address: 
address: service1 
port value: 80 
- name: service2 
connect timeout: 0.25s 
type: strict dns 
lb policy: round robin 
http2 protocol options: {} 
hosts: 
- SOcket address: 
address: service2 
port value: 80 
admin: 
access log path: "/dev/null" 
address: 
Socket address: 
address: 0.0.0.0 
port value: 8001 


我 们 看 到 其 中 包括 了 三 大 配置 项 : 


e static resources : 路 由 配置 信息 

e cluster : envoymesh 的 服务 注册 信息 

e admin: 管理 接口 ， 可 以 通过 访问 8001 端口 的 ， 访 问 /stats 获取 当前 
envoymesh 的 一 些 统计 信息 ， 访 问 /server_info 获取 Envoy 的 版 本 信息 


vw 


使 用 docker-compose 启动 三 个 容器 。 


$ pwd 
envoy/examples/front-proxy 

$ docker-compose up --build -d 
$ docker-compose ps 


Name Command State 
Ports 
example_service1 1 /bin/sh -c /usr/local/bin/ ... Up 
80/tcp 
example service2 1 /bin/sh -c /usr/local/bin/ ... Up 
80/tcp 
example front-envoy 1 /bin/sh -c /usr/local/bin/ ... Up 


0.0.0.0:8000->80/tcp, 0.0.0.0:8001->8001/tcp 


我 们 下 面 将 过 一 人 遍 Envoy 作为 前 端 代 理 的 所 有 功能 ， 这 些 功能 是 通用 功能 。 


路 由 
访问 service1 http://localhost:8000/service/1 将 看 到 如 下 输出 。 


$ curl -v localhost:8000/service/1 
* 


Trying ::1... 

* TCP_NODELAY set 

Connected to localhost (::1) port 8000 (#0) 
GET /service/1 HTTP/1.1 

Host: localhost :8000 

User-Agent: curl/7.54.0 

Accept: */* 


* 


HTTP/1.1 200 OK 

content-type: text/html; charset-utf-8 
content-length: 89 

server: envoy 

date: Fri, 20 Apr 2018 08:26:33 GMT 
x-envoy-upstream-service-time: 14 


人 和 人 AN 人 人 AN 人 ANAANAVVVV V 


< 

Hello from behind Envoy (service 1)! hostname: a3e4185a9a49 reso 
lvedhostname: 172.18.0.4 

* Connection #0 to host localhost left intact 


访问 service2 http://localhost:8000/service/2 将 看 到 如 下 输出 。 


Trying ::1... 
TCP NODELAY set 
Connected to localhost (::1) port 8000 (#0) 
GET /service/2 HTTP/1.1 
Host: localhost:8000 
User-Agent: curl/7.54.0 
Accept: */* 


+ FF 


HTTP/1.1 200 OK 

content-type: text/html; charset=utf-8 
content-length: 89 

server: envoy 

date: Fri, 20 Apr 2018 08:27:27 GMT 
x-envoy-upstream-service-time: 10 


NAN AKA AAANVVVV V 


< 
Hello from behind Envoy (service 2)! hostname: f6650e1911a0 reso 
lvedhostname: 172.18.0.3 

* Connection #0 to host localhost left intact 


我 们 看 到 访问 请 求 被 路 由 到 了 正确 的 服务 后 
负载 均衡 
增加 service1 的 示例 数 。 


$ docker-compose Scale Service1=3 


sw 
Sy o 


WARNING: The scale command is deprecated. Use the up command wit 


h the --scale flag instead. 


Starting frontproxy serviced 1 ... done 

Creating frontproxy servicel1 2 ... done 

Creating frontproxy servicei1 3 ... done 

$ docker-compose ps 

Name Command 

e Ports 

frontproxy front-envoy 1 /usr/bin/dumb-init -- /bin 
10000/tcp, 0.0.0.0:8000->80/tcp, 0.0.0.0:8001->8001/tcp 

frontproxy_service1_1 /bin/sh -c /usr/local/bin/ 
10000/tcp, 80/tcp 

frontproxy servicei 2 /bin/sh -c /usr/local/bin/ 
10000/tcp, 80/tcp 

frontproxy servicei 3 /bin/sh -c /usr/local/bin/ 
10000/tcp, 80/tcp 

frontproxy service2 1 /bin/sh -c /usr/local/bin/ 


10000/tcp, 80/tcp 


我 们 看 到 现在 serviced 已 经 有 了 3 个 实例 ， 现 在 再 访问 service 


http://localhost:8000/service/1 ° 


$ while true;do curl localhost:8000/service/1;sleep 1;done 
Hello from behind Envoy (service 1)! hostname: 


lvedhostname: 172.18.0.4 


Hello from behind Envoy (service 1)! hostname: 


lvedhostname: 172.18.0.5 


Hello from behind Envoy (service 1)! hostname: c5b9f1289e0f 


lvedhostname: 172.18.0.6 


Hello from behind Envoy (service 1)! hostname: a3e4185a9a49 


lvedhostname: 172.18.0.4 


Hello from behind Envoy (service 1)! hostname: fe44dba64122 


lvedhostname: 172.18.0.5 


Hello from behind Envoy (service 1)! hostname: c5b9f1289e0f 


lvedhostname: 172.18.0.6 


a3e4185a9a49 


fe44dba64122 


reso 


reso 


reso 


reso 


reso 


reso 


我 们 看 到 对 service1 的 已 经 有 负载 均衡 了 ， 使 用 的 策略 是 round_robin ， 这 些 
都 是 在 front-envoy.yaml 文件 中 的 cluster 项 下 配置 的 。 


访问 http://localhost:8001 可 以 看 到 Envoy admin 提供 以 下 管理 API 端点 。 


命令 描述 
/ Admin 主页 
/certs 打印 机 器 上 的 certs 
/clusters upstream cluster 状态 


输出 当前 的 Envoy 配置 
开局 /关闭 CPU profiler 


/config dump 


/cpuprofiler 


/healthcheck/fail 导致 服务 失败 健康 检查 
/healthcheck/ok 导致 服务 通过 健康 检查 
/help 打印 管理 命令 的 帮助 信息 
/hot_restart_version 打印 热 重 局 兼 容 版 本 


打印 listener 地 址 
/logging 查询 /更 改 日 志 级 别 
/quitquitquit 退出 服务 


/listeners 


/reset_counters 
/runtime 
/runtime_modify 
/server_info 
/stats 


/stats/prometheus 


Envoy 提供 了 API 管理 端点 ， 可 以 对 Envoy 进行 动态 配置 


reference。 


将 计数 器 重 置 为 1 

打印 运行 时 值 

修改 运行 时 值 

打印 服务 器 版 本 /状态 信息 
打印 服务 器 状态 统计 信息 


打印 prometheus 格式 的 服务 器 状态 统计 信息 


， 参考 v2 API 


e Front proxy 
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Envoy mesh 教程 
本 文 是 在 Kubernetes 集群 中 ， 使 用 Envoy 来 做 mesh， 来 为 一 个 简单 的 使 用 
Python 编写 的 Flask 应 用 程序 做 反 向 代理 和 负载 均衡 。 


注 : 本 教程 中 的 示例 来 自 envoy-steps， 本 文中 使 用 的 所 有 的 代码 和 YAML 配置 见 
envoy-tutorial ° 








Envoy Mesh in Kubernetes https://github.com/rootsongjc/envoy-tutorial 
`à 
( ` edge-envoy service 


Proxying and load balancing 





usersvc service 


Flask App 


watch 


Pa - 


PostgreSQL 












source https://jimmysong.io 











E A - Envoy Mesh 架 构图 


前 提 条 件 


使 用 kubernetes-vagrant-centos-cluster #84 kubernetes 集群 ， 只 要 启动 集群 并 安 
X T CoreDNS 即 可 ， 无 须 安 装 其 他 插件 。 


部 效应 用 


我 们 首先 将 应 用 部 署 到 Kubernetes 中 。 


部 署 postgres 数据 库 。 
kubectl apply -f postgres 
创建 usersvc 镜像 。 
docker build -t jimmysong/usersvc:step1 . 


#8 # usersvc ° 


kubectl apply -f usersvc 


查看 userve 的 ClusterlP 地 址 。 


$ kubectl get svc usersvc 
kubectl get svc usersvc 


NAME TYPE CLUSTER- IP EXTERNAL - IP PORT(S) 
AGE 

usersvc ClusterIP 10.254.176.248 «none» 5000/TCP 
11m 


it | node4 中 访问 该 服务 ， 因 为 我 们 要 访问 的 是 Clusterl|P， 在 我 们 自己 的 电脑 上 
是 无 法 直接 访问 的 ， 所 以 进 到 虚拟 机 中 操作 。 


$ vagrant ssh node1 
$ curl 10.254.176.248:5000 
{ 
"hostname": "usersvc-7cf5bb9d85 -9gx7w", 
"msg": “user health check OK", 
"ok": true, 
"resolvedname": "172.33.10.7" 


尝试 添加 一 个 名 为 Alice 的 用 户 。 


$ curl -X PUT -H "Content-Type: application/json" \ 
-d '{ "fullname": "Alice", "password": "alicerules" }' \ 
10.254.176.248/user/alice 


将 会 看 到 类 似 如 下 的 输出 。 


{ 
"fullname": "Alice", 
"hostname": "usersvc-7cf5bb9d85 -9gx7w", 
"ok": true, 
"resolvedname": "172.33.10.7", 
"uuid": "EFA3BA75F65848C6BE708F436305864B" 
} 


尝试 再 添加 一 个 名 为 Bob 的 用 户 。 


$ curl -X PUT -H "Content-Type: application/json" \ 
-d '{ "fullname": "Bob", "password": "bobrules" }' \ 
10.254.176.248/user/bob 


将 会 看 到 类 似 如 下 的 输出 。 


{ 
"fullname": "Bob", 
"hostname": "usersvc-7cf5bb9d85 -9gx7w", 
"ok": true, 
"resolvedname": "172.33.10.7", 
"uuid": "6AC944E7D4254D9A811A82COFDAC3046" 
} 


当 应 用 部 署 完 毕 后 ， 我 们 该 部 署 edge envoy T » 


部 署 edge envoy 
部 署 edge envoy 的 方式 很 简单 ， 执 行 下 面 的 命令 。 


kubectl apply -f edge-envoy 


Envoy mesh 教 程 


现在 访问 edge envoy 是 就 可 以 路 由 到 usersvc 上 的 ， 当 然 直 接 访问 usersve 


也 是 可 以 的 。 


我 们 看 下 edge-envoy 的 envoy 配置 文件 定义 。 


"listeners": [ 


"address": "tcp://0.0.0.0:80", 


"filters": | 
{ 
"type" : "read", 
"name": "http connection manager", 
"config": { 
"codec type": "auto", 
"stat prefix": "ingress http", 


"route config": { 
"virtual hosts": [ 


{ 
"name": "backend", 
"domains": pu ; 
"routes": [ 
t 
"timeout ms": 0, 
"prefix": "/user", 
"cluster": "usersvc" 
} 
] 
J 
] 
}, 
"filters": [ 
{ 
"type": "decoder", 
"name": "router", 
"config": {} 
} 
] 
} 
} 
] 
} 
1, 
"admin": ( 


"access log path": "/dev/null", 
"address": "tcp://127.0.0.1:8001" 
tr 
"cluster manager": { 
"clusters": [ 


"name": "usersvc", 


1160 


"connect_timeout_ms": 250, 
"type": “strict_dns", 
"service_name": "usersvc", 
"lb type": "round robin", 
"features": "http2", 
"hosts": | 


"uri": "tcp://usersvc:80" 


客户 端 访问 edge-envoy 的 ClusterIP:8000/user/health 就 可 以 检查 节点 
的 健康 状况 。 


部 署 usersvc2 


删除 原来 的 usersvc ， 部 署 第 二 版 usersvc2 ， 它 与 原来 的 usersvc 唯一 不 


同 的 地 方 是 在 entrypoint 中 集成 了 envoy， 查 看 Dockerfile 中 指定 的 
entrypoint.sh 的 内 容 便 可 知 。 


#!/bin/sh 


python /application/service.py & 
/usr/local/bin/envoy -c /application/envoy.json 


首先 删除 老 的 usersvc ° 
kubectl delete -f usersvc 


使 用 下 面 的 命令 部 署 usersvc2 ， 它 仍然 使 用 usersvc 这 个 service 名 称 。 


kubectl apply -f usersvc2 


Envoy VA out-of-process 的 方式 运行 ， 对 应 用 进程 没有 侵入 性 ， 也 可 以 使 用 
sidecar 的 方式 运行 ， 让 envoy 与 应 用 容器 运行 在 同一 个 pod 中 。 


增加 usersvc2 的 实例 个 数 。 


kubectl 


scale --replicas-3 deployment/usersvc 


此 时 我 们 有 3 个 usersvc 实例 ， 现 在 通过 edge-envoy 的 
ClusterIP:8000/user/health 检查 节点 的 健康 状况 时 ， 是 不 是 会 轮 询 的 访问 到 
后 端的 的 usersvc2 的 实例 呢 ? 


我 们 当初 在 edge-node 的 envoy.json 中 配置 过 Ccluster 的 ， 其 中 指定 了 


lb type 


7] round robin ° 


"cluster manager": ( 
"clusters": [ 


( 


"name": "usersvc", 
"connect timeout ms": 250, 
"tvpe": "strict dns", 
"service name": "usersvc", 
"lb type": "round robin", 
"features": "http2", 
"hosts": [ 


"url": "tcp://usorsvc: 898" 


而 且 该 serivce name 也 可 以 被 DNS 正确 解析 。 


root@usersvc-55b6857d44-gcg5c:/application# nslookup usersvc 


Server: 10.254.0.2 
Address: 10.254.0.2753 
Name: usersvc.envoy-tutorial.svc.cluster.local 


Address: 100.254.123.166 


虽然 通过 DNS 可 以 正确 的 解析 出 serivce 的 ClusterIP， 但 是 负载 均衡 不 再 通过 
kube-proxy 实现 ， 所 以 不 论 我 们 访问 多 少 次 edge-envoy 永远 只 能 访问 到 一 个 固 


定 的 后 端 


usersvc ° 


服务 发 现 服务 - SDS 


Kubernetes 中 的 DNS 可 以 发 现 所 有 serivce 的 ClusterlP » 4222 DNS 中 不 包括 所 
有 endpoint 地 址 ， 我 们 需要 一 个 SDS (服务 发 现 服务 ) 来 发 现 服务 的 所 有 的 
endpoint， 我 们 将 修改 1b type ， 使 用 sds 替代 strict dns 。 


执行 下 面 的 命令 部 署 SDS。 


kubectl apply -f usersvc-sds 


因为 在 添加 了 SDS 之 后 需要 修改 edge-envoy 中 的 envoy.josn 配置 ， 在 
clusters 字段 中 增加 sds 人 信息， 我们 将 所 有 的 配置 都 写 好 了 ， 重 新 打包 成 了 
镜像 ， 我 们 需要 先 删除 之 前 部 署 的 edge-envoy ° 


kubectl delete -f edge-envoy 


部 署 新 的 edge-envoy2 ° 


kubectl apply -f edge-envoy2 


连续 访问 usersvc 12 次 看 看 输出 结果 如 何 。 


URL=http://172.17.8.101:30800/user/alice 
for iin ‘seq 1 12 ;do curl -s $URL|grep "resolvedname"|tr -d " " 
[tr -d ","|tr -d '"';done 


EJE eee | 
我 们 可 以 看 到 类 似 如 下 的 输出 : 


resolvedname:172.33.71. 
resolvedname:172.33.88. 
resolvedname:172.33.10. 
resolvedname:172.33.71. 
resolvedname:172.33.88. 
resolvedname:172.33.10. 
resolvedname:172.33.71. 
resolvedname:172.33.88. 
resolvedname:172.33.10. 
resolvedname:172.33.71. 
resolvedname:172.33.88. 
resolvedname:172.33.10. 


NNNNNNNNN DN DN PN 


再 查看 下 usersvc 服务 的 所 有 pod 的 IP 地 址 。 


$ kubectl get pod -1 service-usersvc -o wide 


NAME READY STATUS RESTARTS AGE 
IP NODE 

usersvc-55b6857d44-mkfpv 1/1 Running 0 9m 
172.33.88.2 node1 

usersvc -55b6857d44-q98jg 171 Running 0 9m 
172.33.71.2 node2 

usersvc-55b6857d44-s2znk 1/1 Running 0 9m 


172.33.10.2 node3 


我 们 看 到 round-robin 负载 均衡 生效 了 。 


e Part 2: Deploying Envoy with a Python Flask webapp and Kubernetes 
e envoy-steps 

e kubernetes-vagrant-centos-cluster 

e envoy-tutorial 
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大 数据 
Kubernetes community 中 已 经 有 了 一 个 Big data SIG， 大 家 可 以 通过 这 个 SIG 了 解 
kubernetes 结 合 大 数据 的 应 用 。 


在 Swarm、Mesos、kubernetes 这 三 种 流行 的 容器 编排 调度 架构 中 ，Mesos 对 于 大 
数据 应 用 支持 是 最 好 的 ，spark 原 生 就 是 运行 在 mesos 上 的 ， 当 然 也 可 以 容器 化 运行 
在 kubernetes 上 。 当 前 在 kubernetes 上 运行 大 数据 应 用 主要 是 spark 应 用 。 


Spark on Kubernetes 


Spark 原 生 支 持 standalone、mesos 和 YARN 的 调度 方式 ， 当 前 kubernetes 社 区 正在 
支持 kubernetes 的 原生 调度 来 运行 spark -。 


当然 您 也 可 以 在 kubernetes 直 接 部 署 spark on yarn 或 者 spark standalone 模 式 ， 仍 
然 沿 用 已 有 的 


Spark Standalone 


i spark standalone 模 式 在 kubernetes 上 运行 ，kubernetes 不 负责 spark 任 务 的 调 
。 参 考 : Spark standalone on Kubernetes 


这 种 模式 中 使 用 的 spark 本 身 负 责任 务 调度 ，kubernetes 只 是 作为 一 个 spark 的 部 署 
平台 。 


Spark on Yarn 


使 用 StatefulSet 和 Headless serverless 来 实现 ， 请 参考 Spark on Yarn 


这 种 模式 中 kubernetes 依 然 不 负责 spark 应 用 的 调度 ， 而 只 是 将 Yarn 换 了 一 个 部 署 
环境 而 已 。 


是 架构 图 : 
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df EL "S{HOSTNANE)" =~ "yarn-mi" 1]; the 
sed -i s/yari 0.0.0/ sHaD00P_PREFIX/etc/hadoop/yarn-site.xmt 





cp S{CONFIG_OIR)/start-yarn-rn.sh SHADUO?_PREFIK/sbin/ 


chmod +x start-yarn-rmsh 
/start-yarm-msh 





meme Kubernetes cluster] Spark on Yarn with kubernetes ER 
ubel 

{ ge ae =e Y [+ > kubectl 

i Pod Pod /4—— Yarn Cluster sal oA 

II. o EEESS ee oe | ( Y 

1 EN < em B Users 

i Volume P Volume [3 

i Hostname, Hostname: i ureem. [7 ENEAKl -— —" |... 
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ker-registry/hadoop-2.6,0-edh5.5,2:v1 








ntig/bootstra 











= nane: hadosp-config 
meuntPath: /trp/hadoop-config 
volunes: 
- nane: hadcop-config 
cont ighap: 


nane: nadeap-contig 





FRON ny-docker-registry/j di: 7u80 
4 Add native tibs 
ARG MADOOP. VERSIUN-2. 6. 0-cdhs. 5.2 





‘ADD hadoop-S{HADOOP VERSION).tar.oz /usr/local 
EW HADOOP_PREFIX=/usr/tocal/hadoop \ 
MADODP. COMIDN, HOHE-/usr/locaU/hadoop V 


RUN V 
cd fusr/local && ln -s ./hadoop-S(HADOOP VERSION} hadoop S& V 
rm -f ${HADOOP_PREFIX)/logs/* 

MORKDIR $HADOOP_PREFTX 

# Hars ports 

EXPOSE 50820 50920 50070 50075 50098 8920 0000 























ee ee Administrator or User defined 


























[à Hapred ports 

EXPOSE 19888 

Yarn ports 

EXPOSE 8930 8021 8032 8033 8040 S042 8058 
#0ther ports 

EXPOSE 49707 2122 














Source htips://github.cam/rootsongjc/kubemetes-handbook 





图 片 - Spark on yarn with kubernetes 


Spark on Kubernetes 


Spark on kubernetes， 使 用 kubernetes 作 为 调度 引擎 ，spark 的 任务 直接 调度 到 


node 节 点 上 。 参 考 : 运行 支持 kubernetes 原 生 调 度 的 Spark 程 序 


调度 方式 总 结 


下 图 显示 的 是 三 种 调度 方式 中 单个 kubernetes node 节 点 上 运行 


调度 情况 。 


的 spark 相 关 容 器 的 





大 数据 





Spark on Kubernetes with different schedulers 


Yarn Standalone Native 








^ 


| Kubelet node Kubelet node 


NodeManager App1 Executor 


App1 Executor 


App2 Executor 





App1 Executor Cepteeonorpoa 


https://jimmysong.io 























图 片 -在 kubernetes 上 使 用 多 种 调度 方式 


毫 无 疑问 ， 使 用 kubernetes 原 生 调 度 的 spark 任 务 才 是 最 节省 资源 的 。 


Copyright © jimmysong.io 2017-2018 all right reserved > powered by 
GitbookUpdated at 2018-05-09 14:15:47 


1167 


Spark standalone on Kubernetes 


BAR A AF Spark standalone 模式 ， 对 资源 的 分 配 调度 还 有 作业 状态 查询 的 功能 
实在 有 限 ， 对 于 让 spark d£ M EGE/ 4-89 kubernetes 资源 调度 推荐 大 家 尝试 
https://github.com/apache-spark-on-k8s/ 


本 文中 使 用 的 镜像 我 已 编译 好 上 传 到 了 时 速 云 上 ， 大 家 可 以 直接 下 载 。 


index.tenxcloud.com/jimmy/spark:1.5.2 v1 
index.tenxcloud.com/jimmy/zeppelin:0.7.1 


代码 和 使 用 文档 见 Github 地 址 : https://github.com/rootsongjc/spark-on-kubernetes 


本 文中 用 到 的 yam 文件 可 以 在 ../manifests/spark-standalone 目录 下 找到 ， 也 可 以 
在 上 面 的 https://github.com/rootsongjc/spark-on-kubernetes/ 项 目的 manifests 4 
录 下 找到 。 


注意 : 时 速 云 上 本 来 已 经 提供 的 镜像 
index.tenxcloud.com/google containers/spark:1.5.2 vi ， 但 是 该 镜像 似 


乎 有 问题 ， 下 载 总 是 失败 。 


在 Kubernetes 上 启动 spark 


创建 名 为 spark-cluster 的 namespace， 所 有 操作 都 在 该 namespace 中 进行 。 


所 有 yaml 文 件 都 在 manifests 目录 下 。 


$ kubectl create -f manifests/ 


将 会 启动 一 个 拥有 三 个 worker 的 spark 集 群 和 zeppelin。 


同时 在 该 naamespace 中 增加 ingress 配 置 ， 将 spark 的 Ul 和 zeppelin 页 面 都 暴露 出 
来 ， 可 以 在 集群 外 部 访问 。 


该 ingress 后 端 使 用 traefik。 


i5 l*] spark 


通过 上 面 对 ingress 的 配置 暴露 服务 ， 需 要 修改 本 机 的 /etc/hosts 文 件 ， 增 加 以 下 配 
置 ， 使 其 能 够 解析 到 上 述 service 。 


» 


172.20.0.119 zeppelin.traefik.io 
172.20.0.119 spark.traefik.io 


172.20.0.119 是 我 设置 的 VIP 地 址 ，VIP 的 设置 和 traefik 的 配置 请 查看 Kubernetes- 
handbook ° 

spark ui 

访问 http://spark.traefik.io 


D Spark Master at spark://spark X 


c C fû © spark.traefik.io/proxy:spark-master:8080 axa UR 





Spaik® 


1.5.2 Spark Master at spark://spark-master:7077 


URL: spark://spark-master:7077 

REST URL: spark://spark-master:6066 (cluster mode) 
Alive Workers: 3 

Cores in use: 120 Total, 0 Used 

Memory in use: 373.9 GB Total, 0.0 B Used 
Applications: 0 Running, 0 Completed 

Drivers: 0 Running, 0 Completed 

Status: ALIVE 


Workers 

Worker Id Address State Cores Memory 
worker-20170509141349-172.30.60.18-36687 172.30.60.18:36687 ALIVE 40 (0 Used) 124.6 GB (0.0 B Used) 
worker-20170509141407-172.30.71.12-37758 172.30.71.12:37758 ALIVE 40 (0 Used) 124.6 GB (0.0 B Used) 
worker-20170509141410-172.30.94.15-33332 172.30.94.15:33332 ALIVE 40 (0 Used) 124.6 GB (0.0 B Used) 
Running Applications 
Application ID Name Cores Memory per Node Submitted Time User State Duration 


Completed Applications 


Application ID Name Cores Memory per Node Submitted Time User State Duration 


图 片 - spark master ui 


Spark standalone on Kubernetes 


zeppelin ui 


访问 http://zepellin.treafik.io 


@ zeppelin.traefik.io/#/ x 





€ [c i5; |! © zeppelin.traefik.io/i#/ Qe Doos: 


> Zeppelin Notebook- Job are 








Welcome to Zeppelin! 


Zeppelin is web-based notebook that enables interactive data analytics. 
You can make beautiful data-driven, interactive, collaborative document with SQL, code and even more! 


Notebook 2 
£, Import note 
1] Create new note 
Q Filter 

C3 Zeppelin Tutorial 
Help 
Get started with Zeppelin documentation 
Community 
Please feel free to help us to improve Zeppelin, 


Any contribution are welcome! 


1$? Mailing list 
X Issues tracking 
©) Github 
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运行 支持 kubernetes 原 生 调 度 的 Spark 程 厅 


TL;DR 这 个 主题 比较 大 ， 该 开源 项 目 也 还 在 不 断 进行 中 ， 我 单独 做 了 一 个 web 用 
来 记录 spark on kubernetes 的 研究 和 最 新 进展 见 : https://jimmysong.io/spark-on- 
k8s 


我 们 之 前 就 在 kubernetes 中 运行 过 standalone 方式 的 spark 集群 ， 见 Spark 
standalone on kubernetes ° 


目前 运行 支持 kubernetes 原生 调度 的 spark 程序 由 Google 主导 ， 目 前 运行 支持 
kubernetes 原生 调度 的 spark 程序 由 Google 主导 ，fork 自 spark 的 官方 代码 库 ， 
见 https://github.com/apache-spark-on-k8s/spark/ ， 属 于 Big Data SIG » 


参与 到 该 项 目的 公司 有 : 


e Bloomberg 
e Google 

e Haiwen 

e Hyperpilot 

e Intel 

e Palantir 

e Pepperdata 
e Red Hat 


为 何 使 用 spark on kubernetes 


使 用 kubernetes 原 生 调 度 的 Spark on kubernetes 是 对 现 有 的 Spark on yarn/mesos 的 
资源 使 用 方式 的 革命 性 的 改进 ， 主 要 表现 在 以 下 几 点 : 


1. Kubernetes 原 生 调 度 : 不 再 需要 二 层 调 度 ， 直 接 使 用 kubernetes 的 资源 调度 功 
能 ， 跟 其 他 应 用 共用 整个 kubernetes 管 理 的 资源 池 ; 

2. 资源 隔离 ， 粒 度 更 细 ; 原先 yarn 中 的 queue 在 spark on kubernetes 中 已 不 存 
在 ， 取 而 代 之 的 是 kubernetes 中 原生 的 namespace， 可 以 为 每 个 用 户 分 别 指定 
一 个 namespace， 限 制 用 户 的 资源 quota ; 

3. 细 粒 度 的 资源 分 配 : 可 以 给 每 个 spark 任 务 指定 资源 限制 ， 实 际 指定 多 少 资源 
就 使 用 多 少 资源 ， 因 为 没有 了 像 yarn 那 样 的 二 层 调 度 ( 圈 地 式 的 ) ， 所 以 可 以 


更 高 效 和 细 粒 度 的 使 用 资源 ; 

.监控 的 变革 : 因为 做 到 了 细 粒 度 的 资源 分 配 ， 所 以 可 以 对 用 户 提交 的 每 一 个 任 
务 做 到 资源 使 用 的 监控 ， 从 而 判断 用 户 的 资源 使 用 情况 ， 所 有 的 metric 都 记录 
在 数据 库 中 ， 甚 至 可 以 为 每 个 用 户 的 每 次 任务 提交 计量 ; 

. 日志 的 变革 : 用 户 不 再 通过 yarn 的 web 页 面 来 查看 任务 状态 ， 而 是 通过 pod 的 
log 来 查看 ， 可 将 所 有 的 kuberentes 中 的 应 用 的 日 志 等 同 看 待 收 集 起 来 ， 然 后 可 
以 根据 标签 查看 对 应 应 用 的 日 志 ; 


所 有 这 些 变 音 都 可 以 让 我 们 更 高 效 的 获取 资源 、 更 有 效率 的 获取 资源 ! 


Spark 概念 说 明 


Apache Spark 是 一 个 围绕 速度 、 易 用 性 和 复杂 分 析 构 建 的 大 数据 处 理 框架 。 最 初 
在 2009 年 由 加 州 大 学 伯克利 分 校 的 AMPLab 开 发 ， 并 于 2010 年 成 为 Apache 的 开源 
项 目 之 一 。 


在 Spark 中 包括 如 下 组 件 或 概念 : 


e Application : Spark Application 的 概念 和 Hadoop 中 的 MapReduce 类 似 ， 
指 的 是 用 户 编写 的 Spark 应 用 程序 ， 包 含 了 一 个 Driver 功能 的 代码 和 分 布 在 集 
群 中 多 个 节点 上 运行 的 Executor 代码 ; 

Driver : Spark 中 的 Driver 即 运行 上 述 Application 的 main() 元 数 并 且 创 建 
SparkContext， 其 中 创建 SparkContext 的 目的 是 为 了 准备 Spark 应 用 程序 的 运 
行 环境 。 在 Spark 中 由 SparkContext 负责 和 ClusterManager 通信 ， 进 行 资 
源 的 申请 、 任 务 的 分 配 和 监控 等 ; 当 Executor 部 分 运行 完毕 后 ，Driver 负 责 将 
SparkContext 关闭 。 通 常用 SparkContext 代表 Driver ; 

Executor : Application 运 行 在 Worker 节点 上 的 一 个 进程 ， 该 进程 负责 运行 
Task， 并 且 负 责 将 数据 存在 内 存 或 者 磁盘 上 ， 每 个 Application 都 有 各 自 独 立 的 
— Executor ° # Spark on Yarn 模 式 下 ， 其 进程 名 称 

为 CoarseGrainedExecutorBackend ， 类 似 于 Hadoop MapReduce 中 的 
YarnChild。 一 个 coarseGrainedExecutorBackend 进程 有 且 仅 有 一 个 
executor 对 象 ， 它 负责 将 Task 包装 成 taskRunner， 并 从 线程 池 中 抽取 出 一 个 
空闲 线程 运行 Task。 每 个 CoarseGrainedExecutorBackend 能 并 行 运行 
Task 的 数量 就 取决 于 分 配给 它 的 CPU 的 个 数 了 ; 

e Cluster Manager : 指 的 是 在 集群 上 获取 资源 的 外 部 服务 ， 目 前 有 : 

o Standalone : Spark 原 生 的 资源 管理 ， 由 Master 负 责 资源 的 分 配 ; 

o Hadoop Yarn : 由 YARN 中 的 ResourceManager 负 责 资源 的 分 配 ; 


Worker : 集群 中 任何 可 以 运行 Application 代 码 的 节点 ， 类 似 于 YARN 中 的 
NodeManager 节 点 。 在 Standalone 模 式 中 指 的 就 是 通过 Slave 文 件 配置 的 
Worker 节 点 ， 在 Spark on Yarn 模 式 中 指 的 就 是 NodeManager 节 点 ; 

作业 (Job) : 包含 多 个 Task 组 成 的 并 行 计 算 ， 往 往 由 Spark Actionf£ + > — 
个 JOB 包含 多 个 RDD 及 作用 于 相应 RDD 上 的 各 种 Operation ; 

阶段 (Stage) : 每 个 Job 会 被 拆 分 很 多 组 Task， 每 组 任务 被 称 为 Stage， 也 可 
称 TaskSet， 一 个 作业 分 为 多 个 阶段 ， 每 一 个 stage 的 分 割 点 是 action。 比 如 一 
个 job 是 : (transformation1 -> transformation1 -> action1 -> transformation3 
-> action2) ， 这 个 job 就 会 被 分 为 两 个 stage， 分 割 点 是 action1 和 action2。 
任务 (Task) : 被 送 到 某 个 Executor 上 的 工作 任务 ; 


Context : 启动 spark application 的 时 候 创 建 ， 作 为 Spark 运行 时 环境 。 


Dynamic Allocation (动态 资源 分 配 ) : 一 个 配置 选项 ， 可 以 将 其 打开 。 从 
Spark1.2 之 后 ， 对 于 On Yarn 模 式 ， 已 经 支持 动态 资源 分 配 (Dynamic 
Resource Allocation) ， 这 样 ， 就 可 以 根据 Application 的 负载 (Task 情况 ) > 
动态 的 增加 和 减少 executors， 这 种 策略 非常 适合 在 YARN 上 使 用 spark-sql 做 数 
据 开 发 和 分 析 ， 以 及 将 spark-sql 作 为 长 服务 来 使 用 的 场景 。Executor 的 动态 分 
配 需 要 在 cluster mode 下 启用 "external shuffle service" ° 
动态 资源 分 配 策略 : 开启 动 态 分 配 策略 后 ，application 会 在 task 因 没有 足够 资 
源 被 挂 起 的 时 候 去 动态 申请 资源 ， 这 意味 着 该 application 现 有 的 executor 无 法 
满足 所 有 task 并 行 运行 。spark 一 轮 一 轮 的 申请 资源 ， 当 有 task 挂 起 或 等 待 
spark.dynamicAllocation.schedulerBacklogTimeout (默认 1s) 时 间 的 时 
候 ， 会 开始 动态 资源 分 配 ; 之 后 会 每 隔 
spark.dynamicAllocation.sustainedSchedulerBacklogTimeout (默认 
1s) 时 间 申 请 一 次 ， 直 到 申请 到 足够 的 资源 。 每 次 申请 的 资源 量 是 指数 增长 的 ， 
即 1,2,4,8 等 。 之 所 以 采用 指数 增长 ， 出 于 两 方面 考虑 : 其 一 ， 开 始 申请 的 少 是 
考虑 到 可 能 application 会 马上 得 到 满足 ; 其 次 要 成 倍增 加 ， 是 为 了 防止 
application 需要 很 多 资源 ， 而 该 方式 可 以 在 很 少 次 数 的 申请 之 后 得 到 满足 。 


架构 设计 


关于 spark standalone 的 局 限 性 与 kubernetes native spark 架构 之 间 的 区 别 请 参考 
Anirudh Ramanathan 在 2016 年 10 月 8 日 提交 的 issue Support Spark natively in 


Kubernetes #34377 ° 


简 而 言 之 ，spark standalone on kubernetes 有 如 下 几 个 缺点 : 


e 无 法 对 于 多 租户 做 隔离 ， 每 个 用 户 都 想 给 pod 申请 node 节点 可 用 的 最 大 的 资 
e Spark 的 master “worker 本 来 不 是 设计 成 使 用 kubernetes 的 资源 调度 ， 这 样 
会 存在 两 层 的 资源 调度 问题 ， 不 利于 与 kuberentes 集成 。 


而 kubernetes native spark 集群 中 ，spark 可 以 调用 kubernetes API 获取 集群 资源 
和 调度 。 要 实现 kubernetes native spark 需要 为 spark 提供 一 个 集群 外 部 的 
manager 可 以 用 来 跟 kubernetes API 交互 。 


调度 器 后 台 


使 用 kubernetes 原生 调度 的 spark 的 基本 设计 思路 是 将 spark 的 driver 和 
executor 都 放 在 kubernetes 的 pod 中 运行 ， 另 外 还 有 两 个 附加 的 组 


件 : ResourceStagingServer 和 KubernetesExternalShuffleService ° 


Spark driver 其 实 可 以 运行 在 kubernetes 集群 内 部 (cluster mode) 可 以 运 外 
48 (client mode) > executor 只 能 运行 在 集群 内 部 ， 当 有 spark 作业 提交 
kubernetes 集群 上 时 ， 调 度 器 后 台 将 会 为 executor pod 设置 如 下 属性 : 


e 使 用 我 们 预先 编译 好 的 包含 kubernetes 支持 的 spark 镜像 ， 然 后 调用 
CoarseGrainedExecutorBackend main class 启动 JVM。 
e 调度 器 后 台 为 executor pod 的 运行 时 注入 环境 变量 ， 例 如 各 种 JVM 参数 ， 包 
括 用 户 在 spark-submit 时 指定 的 那些 参数 。 
e Executor 的 CPU、 内 存 限 制 根据 这 些 注入 的 环境 变量 保存 到 应 用 程序 的 
SparkConf 中 。 
e 可 以 在 配置 中 指定 spark 运行 在 指定 的 namespace 中 。 


参考 : Scheduler backend 文档 


父 装 指南 


我 们 可 以 直接 使 用 官方 已 编译 好 的 docker 镜像 来 部 署 ， 下 面 是 官方 发 布 的 镜像 : 


组 件 镜像 


Spark Driver Image kubespark/spark-driver:v2.1.0-kubernetes- 


0.3.1 
Spark Executor kubespark/spark-executor:v2.1.0-kubernetes- 
Image gc eis 


Spark Initialization kubespark/spark-init:v2.1.0-kubernetes-0.3.1 


Image 
Spark Staging kubespark/spark-resource-staging- 
Server Image server:v2.1.0-kubernetes-0.3.1 


PySpark Driver kubespark/driver-py:v2.1.0-kubernetes-0.3.1 


Image 
PySpark Executor kubespark/executor-py:v2.1.0-kubernetes- 
Image 0.3.1 


我 将 这 些 镜像 放 到 了 我 的 私有 镜像 仓库 中 了 。 


还 需要 安装 支持 kubernetes 的 spark 客户 端 ， 在 这 里 下 
载 : https://github.com/apache-spark-on-k8s/spark/releases 


根据 使 用 的 镜像 版 本 ， 我 下 载 的 是 v2.1.0-kubernetes-0.3.1 
运行 SparkPi 测试 


我 们 将 任务 运行 在 spark-cluster namespace v > È #4 5 个 executor X 
例 o 


./bin/spark-submit \ 
--deploy-mode cluster \ 
--class org.apache.spark.examples.SparkPi \ 
--master k8s://https://172.20.0.113:6443 \ 
--kubernetes-namespace spark-cluster \ 
--conf spark.executor.instances=5 \ 
--conf spark.app.name=spark-pi \ 


--conf spark. kubernetes.driver.docker.image=harbor-001.jimmyso 
ng.io/library/kubespark-spark-driver:v2.1.0-kubernetes-0.3.1 \ 

--conf spark.kubernetes.executor.docker.image=harbor -001. jimmy 
song.io/library/kubespark-spark-executor:v2.1.0-kubernetes-0.3.1 
N 

--conf spark.kubernetes.initcontainer.docker.image-harbor-001. 
jimmysong.io/library/kubespark-spark-init:v2.1.0-kubernetes-0.3. 
3 \ 
local:///opt/spark/examples/jars/spark-examples 2.11-2.1.0-k8s-0 
.3.1-SNAPSHOT. jar 


关于 该 命令 参数 的 介绍 请 参考 : https://apache-spark-on- 
k8s.github.io/userdocs/running-on-kubernetes.html 


注意 : 该 jar 5X RE spark. kubernetes.executor.docker.image 镜像 中 


的 。 
这 时 候 提交 任务 运行 还 是 失败 ， 报 错 信息 中 可 以 看 到 两 个 问题 : 


e Executor 无 法 找到 driver pod 
e HP system:serviceaccount:spark-cluster:defaul 没有 权限 获取 
spark-cluster 中 的 pod 信息 。 


提 了 个 issue Failed to run the sample spark-pi test using spark-submit on the doc 
#478 


需要 为 spark 集群 创建 一 个 serviceaccount 和 clusterrolebinding 


kubectl create serviceaccount spark --namespace spark-cluster 
kubectl create rolebinding spark-edit --clusterrole=edit --servi 
ceaccount=spark-cluster:spark --namespace=spark-cluster 


ik Bug 将 在 新 版 本 中 修复 。 
用 户 指南 

编译 

Fork 并 克隆 项 目 到 本 地 : 


git clone https://github.com/rootsongjc/spark.git 


编译 前 请 确保 你 的 环境 中 已 经 安装 Java8 和 Maven3 » 


> Jt ORE ORA 
~ 35$ 


kubernetes -pl resource-managers/kubernetes/ 


m b bh 22 2L ue 
H4 Xo bà 2X DG 
HH A3 — 4X. Zi VE A) m 


build/mvn install -P 
core -am -DskipTests 


AA 编译 spark on kubernetes 
build/mvn compile -Pkubernetes -pl resource-managers/kubernetes/ 
core -am -DskipTests 


LLL we dó 
HH Ap 


dev/make-distribution.sh --tgz -Phadoop-2.7 -Pkubernetes 
第 一 次 编译 和 发 布 的 过 程 耗 时 可 能 会 比较 长 ， 请 耐心 等 待 ， 如 果 有 依赖 下 载 不 下 
来 ， 请 自 备 梯子 。 


详细 的 开发 指南 请 见 : https://github.com/apache-spark-on-k8s/spark/blob/branch- 
2.2-kubernetes/resource-managers/kubernetes/README.md 


构建 镜像 


使 用 该 脚本 来 自动 构建 容器 镜像 : https://github.com/apache-spark-on- 
k8s/spark/pull/488 


将 该 脚本 放 在 dist 目录 下 ， 执 行 : 


./build-push-docker-images.sh -r harbor-001.jimmysong.io/library 
-t v2.1.0-kubernetes-0.3.1-1 build 
./build-push-docker-images.sh -r harbor-001.jimmysong.io/library 
-t v2.1.0-kubernetes-0.3.1-1 push 


注意 : 如 果 你 使 用 的 MacOS : bash 的 版 本 可 能 太 低 ， 执 行 改 脚本 将 出 错 ， 请 检查 
你 的 bash 版 本 : 


bash --version 
GNU bash, version 3.2.57(1)-release (x86 64-apple-darwini6) 
Copyright (C) 2007 Free Software Foundation, Inc. 


上 面 我 在 升级 bash 之 前 获取 的 版 本 信息 ， 使 用 下 面 的 命令 升级 bash : 


brew install bash 


升级 后 的 bash 版 本 为 4.4.12(1)-release (x86 64-apple-darwini6.3.0) ° 


编译 并 上 传 镜像 到 我 的 私有 镜像 仓库 ， 将 会 构建 出 如 下 几 个 镜像 : 


harbor-001.jimmysong.io/library/spark-driver:v2.1.0-kubernetes-0 
.3.1-1 
harbor-001.jimmysong.io/library/spark-resource-staging-server:v2 
.1.0-kubernetes-0.3.1-1 
harbor-001.jimmysong.io/library/spark-init:v2.1.0-kubernetes-0.3 
.1-1 
harbor-001.jimmysong.io/library/spark-shuffle:v2.1.0-kubernetes- 
0.3.1-1 
harbor-001.jimmysong.io/library/spark-executor:v2.1.0-kubernetes 
-0.3.1-1 
harbor-001.jimmysong.io/library/spark-executor-py:v2.1.0-kuberne 
tes-0.3.1-1 
harbor-001.jimmysong.io/library/spark-driver-py:v2.1.0-kubernete 
s-0.3.1-1 


运行 测试 
在 dist/bin 目录 下 执行 spark-pi 测试 : 


./spark-submit \ 

--deploy-mode cluster \ 

--class org.apache.spark.examples.SparkPi \ 

--master k8s://https://172.20.0.113:6443 \ 

--kubernetes-namespace spark-cluster \ 

--conf spark.kubernetes.authenticate.driver.serviceAccountName- 
spark \ 

--conf spark.executor.instances=5 \ 

--conf spark.app.name=spark-pi \ 

--conf spark.kubernetes.driver.docker.image-harbor-001.jimmyso 
ng.io/library/spark-driver:v2.1.0-kubernetes-0.3.1-1 \ 

--conf spark.kubernetes.executor.docker.image-harbor-001.jimmy 
song.io/library/spark-executor:v2.1.0-kubernetes-0.3.1-1 \ 

--conf spark.kubernetes.initcontainer.docker.image-harbor-001. 
jimmysong.io/library/spark-init:v2.1.0-kubernetes-0.3.1-1 \ 
local:///opt/spark/examples/jars/spark-examples 2.11-2.2.0-k8s-0 
.4.0-SNAPSHOT.jar 


| ———————————————————————  "uUf | 


详细 的 参数 说 明 见 : https://apache-spark-on-k8s.github.io/userdocs/running-on- 
kubernetes.html 


注意 : local:///opt/spark/examples/jars/spark-examples 2.11-2.2.0- 
k8s-0.4.0-SNAPSHOT.jar 文件 是 在 spark-driver 和 spark-executor 4% 
像 里 的 ， 在 上 一 步 构建 镜像 时 已 经 构建 并 上 传 到 了 镜像 仓库 中 。 


2017-09-14 14:59:01 INFO Client:54 - Waiting for application sp 
ark-pi to finish... 
2017-09-14 14:59:01 INFO LoggingPodStatusWatcherImpl:54 - State 
changed, new state: 
pod name: spark-pi-1505372339796-driver 
namespace: spark-cluster 
labels: spark-app-selector -> spark-f4d3a5d3ad964a05a51feb6 
191450357, spark-role -> driver 
pod uid: 304cf440-991a-11e7-970c-f4e9d49f8edO 
creation time: 2017-09-14T06:59:01Z 
service account name: spark 
volumes: spark-token-zr8wv 
node name: N/A 
start time: N/A 
container images: N/A 
phase: Pending 
status: [] 
2017-09-14 14:59:01 INFO LoggingPodStatusWatcherImpl:54 - State 
changed, new state: 
pod name: spark-pi-1505372339796-driver 
namespace: spark-cluster 
labels: spark-app-selector -> spark-f4d3a5d3ad964a05a51feb6 
191450357, spark-role -> driver 
pod uid: 304cf440-991a-11e7-970c-f4e9d49f8edO 
creation time: 2017-09-14T06:59:01Z 
service account name: spark 
volumes: spark-token-zr8wv 
node name: 172.20.0.114 
start time: N/A 
container images: N/A 
phase: Pending 
status: [] 
2017-09-14 14:59:01 INFO LoggingPodStatusWatcherImpl:54 - State 
changed, new state: 
pod name: spark-pi-1505372339796-driver 
namespace: spark-cluster 
labels: spark-app-selector -> spark-f4d3a5d3ad964a05a51feb6 
191450357, spark-role -> driver 
pod uid: 304cf440-991a-11e7-970c-f4e9d49f8edO 
creation time: 2017-09-14T06:59:01Z 
service account name: spark 
volumes: spark-token-zr8wv 
node name: 172.20.0.114 
start time: 2017-09-14T06:59:01Z 
container images: harbor-001.jimmysong.io/library/spark-dri 


ver:v2.1.0-kubernetes-0.3.1-1 

phase: Pending 

status: [ContainerStatus(containerID=null, image=harbor-001 
.jimmysong.io/library/spark-driver:v2.1.0-kubernetes-0.3.1-1, im 
ageID-, lastState-ContainerState(running-null, terminated-null, 
waiting-null, additionalProperties={}), name=spark-kubernetes-dr 
iver, ready=false, restartCount=0, state=ContainerState(running= 
null, terminated-null, waiting-ContainerStateWaiting(message-nul 
1, reason-ContainerCreating, additionalProperties={}), additiona 
1Properties={}), additionalProperties={}) ] 
2017-09-14 14:59:03 INFO LoggingPodStatusWatcherImpl:54 - State 
changed, new state: 

pod name: spark-pi-1505372339796-driver 

namespace: spark-cluster 

labels: spark-app-selector -> spark-f4d3a5d3ad964a05a5ifeb6 
191450357, spark-role -> driver 

pod uid: 304cf440-991a-11e7-970c-f4e9d49f8edO 

creation time: 2017-09-14T06:59:01Z 

service account name: spark 

volumes: spark-token-zr8wv 

node name: 172.20.0.114 

start time: 2017-09-14T06:59:01Z 

container images: harbor-001.jimmysong.io/library/spark-dri 
ver:v2.1.0-kubernetes-0.3.1-1 

phase: Running 

status: [ContainerStatus(containerID-docker://5c5c821c482a1 
e35552adccb567020532b79244392374f25754f0050e6cd4c62, image-harbo 
r-001.jimmysong.io/library/spark-driver:v2.1.0-kubernetes-0.3.1- 
1, imageID-docker-pullable://harbor-001.jimmysong.io/library/spa 
rk-driverQsha256:beb92a3e3f178e286d9e5baebdead88b5ba76d651f347ad 
2864bbef8eda26f94, lastState-ContainerState(running-null, termin 
ated-null, waiting-null, additionalProperties={}), name-spark-ku 
bernetes-driver, ready-true, restartCount=0, state=ContainerState 
(running-ContainerStateRunning(startedAt-2017-09-14T06:59:02Z, a 
dditionalProperties={}), terminated-null, waiting-null, addition 
alProperties={}), additionalProperties={}) ] 
2017-09-14 14:59:12 INFO LoggingPodStatusWatcherImpl:54 - State 
changed, new state: 

pod name: spark-pi-1505372339796-driver 

namespace: spark-cluster 

labels: spark-app-selector -> spark-f4d3a5d3ad964a05a51feb6 
191450357, spark-role -> driver 

pod uid: 304cf440-991a-11e7-970c-f4e9d49f8edO 

creation time: 2017-09-14T06:59:01Z 

service account name: spark 

volumes: spark-token-zr8wv 

node name: 172.20.0.114 

start time: 2017-09-14T06:59:01Z 

container images: harbor-001.jimmysong.io/library/spark-dri 
ver:v2.1.0-kubernetes-0.3.1-1 

phase: Succeeded 

status: [ContainerStatus(containerID-docker://5c5c821c482a1 
e35552adccb567020532b79244392374f25754f0050e6cd4c62, image-harbo 


r-001.jimmysong.io/library/spark-driver:v2.1.0-kubernetes-0.3.1- 
1, imageID-docker-pullable://harbor-001.jimmysong.io/library/spa 
rk-driverQsha256:beb92a3e3f178e286d9e5baebdead88b5ba76d651f347ad 
2864bbef8eda26f94, lastState-ContainerState(running-null, termin 
ated-null, waiting-null, additionalProperties={}), name-spark-ku 
bernetes-driver, ready-false, restartCount-0, state-ContainerSta 
te(running-null, terminated-ContainerStateTerminated(containerID- 
docker://5c5c821c482a1e35552adccb567020532b79244392374f25754f 005 
0e6cd4c62, exitCode-0, finishedAt-2017-09-14T06:59:11Z, message- 
null, reason-Completed, signal-null, startedAt-null, additionalP 
roperties={}), waiting-null, additionalProperties={}), additiona 
1Properties={}) ] 

2017-09-14 14:59:12 INFO LoggingPodStatusWatcherImpl:54 - Conta 
iner final statuses: 


Container name: spark-kubernetes-driver 

Container image: harbor-001.jimmysong.io/library/spark-driv 
er:v2.1.0-kubernetes-0.3.1-1 

Container state: Terminated 

Exit code: 0 
2017-09-14 14:59:12 INFO Client:54 - Application spark-pi finis 
hed. 
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使 用 下 面 的 命令 可 以 看 到 kubernetes 启动 的 Pod 信息 : 


kubectl --namespace spark-cluster get pods -w 


将 会 看 到 spark-driver 和 spark-exec 的 Pod 信息。 


依赖 管理 


上 文中 我 们 在 运行 测试 程序 时 ， 命 令 行 中 指定 的 jar 文件 已 包含 在 docker 镜像 中 ， 
是 不 是 说 我 们 每 次 提交 任务 都 需要 重新 创建 一 个 镜像 呢 ? 非 也 | te RA TELA 
麻烦 了 。 


创建 resource staging server 


为 了 方便 用 户 提 交 任 务 ， 不 需要 每 次 提交 任务 的 时 候 都 创建 一 个 镜像 ， 我 们 使 用 了 
resource staging server 。 


kubectl create -f conf/kubernetes-resource-staging-server.yaml 


我 们 同样 将 其 部 署 在 spark-cluster namespace T > 7X yaml 文件 见 
kubernetes-handbook 的 manifests/spark-with-kubernetes-native- 
scheduler 目录 。 


优化 


其 中 有 一 点 需要 优化 ， 在 使 用 下 面 的 命令 提交 任务 时 ， 使 用 --conf 
spark.kubernetes.resourceStagingServer.uri 参数 指定 resource staging 
server 地 址 ， 用 户 不 应 该 关注 resource staging server 究竟 运行 在 哪 台 宿主 机 上 ， 
可 以 使 用 下 面 两 种 方式 实现 : 


e 使 用 nodeSelector 将 resource staging server 固定 调度 到 某 一 台 机 器 上 ， 
该 地 址 依然 使 用 宿主 机 的 IP 地 址 

e 改变 spark-resource-staging-service service 的 type 为 ClusterlP > 
然后 使 用 Ingress 将 其 暴露 到 集群 外 部 ， 然 后 加 入 的 内 网 DNS 里， 用户 使 用 
DNS 名 称 指定 resource staging server 的 地 址 。 


然后 可 以 执行 下 面 的 命令 来 提交 本 地 的 jar 到 kubernetes 上 运行 。 


./spark-submit \ 

--deploy-mode cluster \ 

--class org.apache.spark.examples.SparkPi \ 

--master k8s://https://172.20.0.113:6443 \ 

--kubernetes-namespace spark-cluster \ 

--conf spark.kubernetes.authenticate.driver .serviceAccountName= 
spark \ 

--conf spark.executor.instances=5 \ 

--conf spark.app.name=spark-pi \ 

--conf spark.kubernetes.driver.docker.image-harbor-001.jimmyso 
ng.io/library/spark-driver:v2.1.0-kubernetes-0.3.1-1 \ 

--conf spark.kubernetes.executor.docker.image-harbor-001.jimmy 
song.io/library/spark-executor:v2.1.0-kubernetes-0.3.1-1 \ 

--conf spark.kubernetes.initcontainer.docker.image-harbor-001. 
jimmysong.io/library/spark-init:v2.1.0-kubernetes-0.3.1-1 \ 

--conf spark.kubernetes.resourceStagingServer.uri-http://172.2 
0.0.114:31000 \ 

../examples/jars/spark-examples 2.11-2.2.0-k8s-0.4.0-SNAPSHOT. 
jar 


m o > 








该 命令 将 提交 本 地 的 ,./examples/jars/spark-examples_2.11-2.2.0-k8s- 
0.4.0-SNAPSHOT.jar 文件 到 resource staging server > executor 将 从 该 server 
上 获取 jar 包 并 运行 ， 这 样 用 户 就 不 需要 每 次 提交 任务 都 编译 一 个 镜像 了 。 


详 见 : https://apache-spark-on-k8s.github.io/userdocs/running-on- 
kubernetes.html#dependency-management 


设置 HDFS 7l P 


如 果 Hadoop 集群 没有 设置 kerbros 安全 认证 的 话 ， 在 指定 spark-submit 的 时 
候 可 以 通过 指定 如 下 四 个 环境 变量 ， 设 置 Spark 与 HDFS 通信 使 用 的 用 户 : 


--conf spark.kubernetes.driverEnv.SPARK_USER=hadoop 
--conf spark.kubernetes.driverEnv.HADOOP_USER_NAME=hadoop 
--conf spark.executorEnv.HADOOP_USER_NAME=hadoop 

--conf spark.executorEnv.SPARK_USER=hadoop 


使 用 hadoop 用 户 提交 本 地 jar 包 的 命令 示例 : 


./spark-submit \ 

--deploy-mode cluster \ 

--class com.talkingdata.alluxio.hadooptest \ 

--master k8s://https://172.20.0.113:6443 \ 

--kubernetes-namespace spark-cluster \ 

--conf spark. kubernetes.driverEnv.SPARK_USER=hadoop \ 

--conf spark.kubernetes.driverEnv.HADOOP_USER_NAME=hadoop \ 

--conf spark.executorEnv.HADOOP_USER_NAME=hadoop \ 

--conf spark.executorEnv.SPARK_USER=hadoop \ 

--conf spark. kubernetes.authenticate.driver.serviceAccountName= 
spark \ 

--conf spark.executor.instances=5 \ 

--conf spark.app.name=spark-pi \ 

--conf spark.kubernetes.driver.docker.image-harbor-001.jimmyso 
ng.io/library/spark-driver:v2.1.0-kubernetes-0.3.1-1 \ 

--conf spark.kubernetes.executor.docker.image-harbor-001.jimmy 
song.io/library/spark-executor:v2.1.0-kubernetes-0.3.1-1 \ 

--conf spark.kubernetes.initcontainer.docker.image-harbor-001. 
jimmysong.io/library/spark-init:v2.1.0-kubernetes-0.3.1-1 \ 

--conf spark.kubernetes.resourceStagingServer.uri-http://172.2 
0.0.114:31000 \ 
~/Downloads/tendcloud_2.10-1.0.jar 


El — 








if JL : https://github.com/apache-spark-on-k8s/spark/issues/408 


限制 Driver 和 Executor 的 资源 使 用 


在 执行 spark-submit 时 使 用 如 下 参数 设置 内 存 和 CPU 资源 限制 : 


--conf spark.driver.memory-3G 
--conf spark.executor.memory-3G 
--conf spark.driver.cores-2 
--conf spark.executor.cores-10 


这 几 个 参数 中 值 如 何 传递 到 Pod 的 资源 设置 中 的 呢 ? 


比如 我 们 设置 在 执行 spark-submit 的 时 候 传递 了 这 样 的 两 个 参数 : --conf 
spark.driver.cores=2 和 --conf spark.driver.memory-100G 那么 查看 
driver pod 的 yaml 输出 结果 将 会 看 到 这 样 的 资源 设置 : 


resources: 
limits: 
memory: 110Gi 
requests: 
cpu: "2" 
memory: 100Gi 


以 上 参数 是 对 request fake a> BA limit 的 资源 设置 的 值 又 是 从 何 而 
来 ? 


可 以 使 用 spark.kubernetes.driver.limit.cores 和 
spark.kubernetes.executor.limit.cores 来 设置 CPU 的 hard limit ° 


memory limit 的 值 是 根据 memory request 的 值 加 上 
spark.kubernetes.executor.memoryOverhead 的 值 计算 而 来 的 ， 该 配置 项 用 
于 设置 分 配给 每 个 executor 的 超过 heap 内 存 的 值 (可 以 使 用 k、m、g 单 位 ) 。 该 
值 用 于 虚拟 机 的 开销 、 其 他 本 地 服务 开销 。 根 据 executor 的 大 小 设置 (通常 是 6% 

到 10%) ° 


我 们 可 以 这 样 来 提交 一 个 任务 ， 同 时 设置 driver 和 executor 的 CPU、 内 存 的 资源 
request fe limit 44 (driver 的 内 存 limit 444 request 值 的 110%) ° 


./spark-submit \ 

--deploy-mode cluster \ 

--class org.apache.spark.examples.SparkPi \ 

--master k8s://https://172.20.0.113:6443 \ 

--kubernetes-namespace spark-cluster \ 

--conf spark.kubernetes.authenticate.driver .serviceAccountName= 
spark \ 

--conf spark.driver.memory=100G \ 

--conf spark.executor.memory=10G \ 

--conf spark.driver.cores=30 \ 

--conf spark.executor.cores=2 \ 

--conf spark.driver.maxResultSize-10240m \ 

--conf spark.kubernetes.driver.limit.cores-32 \ 

--conf spark. kubernetes.executor.limit.cores=3 \ 

--conf spark. kubernetes.executor.memoryOverhead=2g \ 

--conf spark.executor.instances=5 \ 

--conf spark.app.name=spark-pi \ 

--conf spark.kubernetes.driver.docker.image-harbor-001.jimmyso 
ng.io/library/spark-driver:v2.1.0-kubernetes-0.3.1-1 \ 

--conf spark.kubernetes.executor.docker.image-harbor-001.jimmy 
song.io/library/spark-executor:v2.1.0-kubernetes-0.3.1-1 \ 

--conf spark.kubernetes.initcontainer.docker.image-harbor-001. 
jimmysong.io/library/spark-init:v2.1.0-kubernetes-0.3.1-1 \ 
local:///opt/spark/examples/jars/spark-examples 2.11-2.2.0-k8s-0 
.4.0-SNAPSHOT.jar 10000000 


prac -————M—— ————————— ee) uen 
这 将 启动 一 个 包含 一 千 万 个 task 的 计算 pi 的 spark 任务 ， 任 务 运行 过 程 中 ，drvier 


的 CPU 实际 消耗 大 约 为 3 核 ， 内 存 40G， 每 个 executor 的 CPU 实际 消耗 大 约 不 
到 1 核 ， 内 存 不 到 4G， 我 们 可 以 根据 实际 资源 消耗 不 断 优化 资源 的 request 值 。 


SPARK DRIVER MEMORY 和 SPARK EXECUTOR MEMORY 和 分 别 作 为 Driver 容器 
和 Executor 容器 局 动 的 环境 变量 ， 比 如 下 面 这 个 Driver 启动 的 CMD 中 : 


运行 支持 Kubernetes 原 生 调 度 的 Spark 程 序 


CMD SPARK_CLASSPATH="${SPARK_HOME}/jars/*" && \ 

env | grep SPARK JAVA OPT | sed 's/[4=]*=\(.*\)/\1/g' > /tm 
p/java opts.txt && \ 

readarray -t SPARK DRIVER JAVA OPTS « /tmp/java opts.txt && 
N 

if ! [ -z $(SPARK MOUNTED CLASSPATH*4x) ]; then SPARK CLASSPA 
THZ"$SPARK MOUNTED CLASSPATH:$SPARK CLASSPATH"; fi && \ 

if ! [ -z $(SPARK SUBMIT EXTRA CLASSPATH-*x) ]; then SPARK CL 
ASSPATH-"$SPARK SUBMIT EXTRA CLASSPATH:$SPARK CLASSPATH"; fi && 
N 

if ! [ -z $(SPARK EXTRA CLASSPATH*x) ]; then SPARK CLASSPATH- 
"SSPARK EXTRA CLASSPATH:S$SPARK CLASSPATH"; fi && \ 

if ! [ -z $(SPARK MOUNTED FILES DIR+x} ]; then cp -R "$SPARK 
. MOUNTED FILES DIR/." .; fi && \ 

if ! [ -z $(SPARK MOUNTED FILES FROM SECRET DIR) ]; then cp 
-R "$SPARK MOUNTED FILES FROM SECRET DIR/." .; fi && \ 

$(JAVA HOME)/bin/java "$(SPARK DRIVER JAVA OPTS[Q])" -cp $SP 
ARK CLASSPATH -Xms$SPARK DRIVER MEMORY -Xmx$SPARK DRIVER MEMORY 
$SPARK DRIVER CLASS $SPARK DRIVER ARGS 


ES 


我 们 可 以 看 到 对 SPARK DRIVER MEMORY 环境 变量 的 引用 。Executor 的 设置 与 
driver 类 似 。 


而 我 们 可 以 使 用 这 样 的 参数 来 传递 环境 变量 的 值 spark.executorEnv， 
[EnvironmentVariableName] ， 只 要 将 EnvironmentVariableName 替换 为 环 
境 变 量 名 称 即 可 。 


e Spark 动 态 资源 分 配 -Dynamic Resource Allocation 

e Running Spark on Kubernetes 

e Apache Spark Jira Issue - 18278 - SPIP: Support native submission of spark 
jobs to a kubernetes cluster 

e Kubernetes Github Issue - 34377 Support Spark natively in Kubernetes 

e Kubernetes example spark 

e https://github.com/rootsongjc/spark-on-kubernetes 

e Scheduler backend 

e Introduction to Spark on Kubernetes - banzaicloud.com 

e Scaling Spark made simple on Kubernetes - banzaicloud.com 

e The anatomy of Spark applications on Kubernetes - banzaicloud.com 

e Monitoring Apache Spark with Prometheus - banzaicloud.com 
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ie 4r E HK bernete: là + 7 Æ 44 SnarkZ?2 EG 
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e Running Zeppelin Spark notebooks on Kubernetes - banzaicloud.com 
e Apache Spark CI/CD workflow howto - banzaicloud.com 


Copyright © jimmysong.io 2017-2018 all right reserved * powered by 
GitbookUpdated at 2018-05-09 14:15:47 
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Serverless 2844 


Serverless 2274 


Serverless (无 服务 器 架构 ) 指 的 是 由 开发 者 实现 的 服务 端 逻 辑 运行 在 无 状态 的 计 
算 容器 中 ， 它 由 事件 触发 ， 完 全 被 第 三 方 管理 ， 其 业务 层面 的 状态 则 被 开发 者 使 用 
的 数据 库 和 存储 资源 所 记录 。 


下 图 来 自 谷歌 云 平台 官网 ， 是 对 云 计算 的 一 个 很 好 的 分 层 概括 ， 其 中 serverless 就 
是 构建 在 诬 拟 机 和 容器 之 上 的 一 层 ， 与 应 用 本 身 的 关系 更 加 密切 。 


Serverless 


Infrastructure 


Virtual Machines 


SS |) SS 





Bare Metal 





图 片 - 从 物理 机 到 函数 计算 


Serverless 架 构 的 优点 
今天 大 多 数 公司 在 开发 应 用 程序 并 将 其 部 署 在 服务 器 上 的 时 候 ， 无 论 是 选择 公有 云 


还 是 私有 的 数据 中 心 ， 都 需要 提前 了 解 究竟 需要 多 少 台 服 务 器 、 多 大 容量 的 存储 和 
数据 库 的 功能 等 。 并 需要 部 署 运行 应 用 程序 和 依赖 的 软件 到 基础 设施 之 上 。 假 设 我 
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们 不 想 在 这 些 细节 上 花费 精力 ， 是 否 有 一 种 简单 的 架构 模型 能 够 满足 我 们 这 种 想 
法 ?这 个 答案 已 经 存在 ， 这 就 是 今天 软件 架构 世界 中 新 鲜 但 是 很 热门 的 一 个 话题 
一 Serverless (无 服务 器 ) 架构 。 


一 一 AWS ®# RE 
e 降低 运营 成 本 : 


Serverless 是 非常 简单 的 外 包 解 决 方案 。 它 可 以 让 您 委托 服务 提供 商 管理 服务 器 、 
数据 库 和 应 用 程序 甚至 逻辑 ， 和 否则 您 就 不 得 不 自己 来 维护 。 由 于 这 个 服务 使 用 者 的 
数量 会 非常 庞大 ， 于 是 就 会 产生 规模 经 济 效应 。 在 降低 成 本 上 包含 了 两 个 方面 ， 即 
基础 设施 的 成 本 和 人 员 (运营 /开发 ) 的 成 本 。 


e 降低 开发 成 本 : 


laaS 和 PaaS 存 在 的 前 提 是 ， 服 务 器 和 操作 系统 管理 可 以 商品 化 。Serverless 作 为 另 
一 种 服务 的 结果 是 整个 应 用 程序 组 件 被 商品 化 。 


e 扩展 能 力 : 
Serverless 架 构 一 个 显而易见 的 优点 即 " 横 向 扩展 是 完全 自动 的 、 有 弹性 的 、 且 由 服 
务 提 供 者 所 管理 "。 从 基本 的 基础 设施 方面 受益 最 大 的 好 处 是 ， 您 只 需 支 付 您 所 需要 
的 计算 能 8 

e 更 简单 的 管理 : 
Serverless 架 构 明显 比 其 他 架构 更 简单 。 更 少 的 组 件 ， 就 意味 着 您 的 管理 开销 会 更 
少 o 

e “绿色 ”的 计算 : 


RR GARM) AEAN > dE lk Ae 4e 3 GE P 85 AUIS RRAS 
15% 的 平均 最 大 处 理 能 力 的 输出 。 这 无 疑 是 一 种 资源 的 巨大 浪费 。 随 着 Serverless 
架构 的 出 现 ， 让 服务 提供 商 提供 我 们 的 计算 能 力 最 大 限度 满足 实时 需求 。 这 将 使 我 
们 更 有 效 地 利用 计算 资源 。 


Kubernetes 上 的 serverless 274 


目前 已 经 有 一 批 优秀 的 基于 kubernetes 的 serverless 架构 (FaaS) 开源 项 目 如 
F: 


e faas - Functions as a Service - a serverless framework for Docker & 
Kubernetes https://blog.alexellis.io/introducing... 

e faas-netes - Enable Kubernetes as a backend for Functions as a Service 
(OpenFaaS) https://github.com/alexellis/faas 

e fn - The container native, cloud agnostic serverless platform. http://fnproject.io 

e funktion - a CLI tool for working with funktion https://funktion.fabric8.io/ 

e fx - Poor man's serverless framework based on Docker, Function as a 
Service with painless. 

e |ronFunctions - IronFunctions - the serverless microservices platform. 
http://iron.io 

e kubeless - Kubernetes Native Serverless Framework hittp://kubeless.io 

e OpenWhisk - Apache OpenWhisk (Incubating) is a serverless, open source 
cloud platform that executes functions in response to events at any scale. 


以 上 项 目 收 录 于 awsome-cloud-native 


FaaS 


Function-as-a-Service 424 (图 片 来 自 


https://github.com/amyers1793/FunctionasaServiceLandscape) 


Function-as-a-Service Landscape 44 Redpoint 
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图 片 - FaaS Landscape 


Serverless Architectures - Martin Fowler 
Serverless 414 2s it 

2017 年 会 是 Serverless 爆 发 之 年 吗 ? 

从 laaS 到 FaaS 一 一 Serverless 架 构 的 前 世 今 生 
Introducing Redpoint's FaaS Landscape 


Copyright © jimmysong.io 2017-2018 all right reserved * powered by 
GitbookUpdated at 2018-05-09 14:15:47 


38g ff Serverless 


No silver bullet. - The Mythical Man-Month 


许多 年 前 ， 我 们 开发 的 软件 还 是 C/S (客户 端 / 服 务 器 ) 和 MVC (模型 -试图 -控制 
器 ) 的 形式 ， 再 后 来 有 了 SOA， 最 近 几 年 又 出 现 了 微服 务 架 构 ， 更 新 一 点 的 有 
Cloud Native ( 云 原生 ) 应 用 ， 企 业 应 用 从 单 体 架 构 ， 到 服务 化 ， 再 到 更 细 粒 度 的 
微服 务 化 ， 应 用 开发 之 初 就 是 为 了 应 对 互联 网 的 特有 的 高 并 发 、 不 间断 的 特性 ， 需 
要 很 高 的 性 能 和 可 扩展 性 ， 人 们 对 软件 开发 的 追求 孜孜 不 倦 ， 布 望 力求 在 软件 开发 
的 复杂 度 和 效率 之 间 达 到 一 个 平衡 。 但 可 惜 的 是 ，NO SILVER BULLET ! 几 十 年 前 
(1975 年 ) Fred Brooks 就 在 The Mythical Man-Month F # 5 2] f 3x 4) 18 » ABA 
Serverlss 2 X AB Fil 4R 58 °? 


云 改变 了 我 们 对 操作 系统 的 认 知 ， 原 来 一 个 系统 的 计算 资源 、 存 储 和 网 络 是 可 以 分 
离 配置 的 ， 而 且 还 可 以 弹性 扩展 ， 但 是 长 久 以 来 ， 我 们 在 开发 应 用 时 始终 没有 摆脱 
的 服务 器 的 束缚 (或 者 说 认 知 ) ， 应 用 必须 运行 在 不 论 是 实体 还 是 虚拟 的 服务 器 
上 ， 必 须 经 过 部 署 、 配 置 、 d RAE ， 还 需要 对 服务 器 和 应 用 进行 监控 和 
管理 ， 还 需要 保证 数据 的 安全 性 ， 我 们 简化 吗 ? 让 我 们 只 要 关注 自己 
代码 的 逻辑 就 好 了 ， 其 它 LRAT e 


Serverless^| 22 


Serverless 架 构 是 云 的 自然 延伸 ， 为 了 理解 serverless， 我 们 有 必要 回顾 一 下 云 计算 
的 发 展 。 


laaS 


2006 年 AWS 推 出 EC2 (Elastic Compute Cloud) ， 作 为 第 一 代 

laaS (Infrastructure as a Service) ， 用 户 可 以 通过 AWS 快 速 的 申请 到 计算 资源 ， 
并 在 上 面部 署 自己 的 互联 网 服务 。laaS 从 本 质 上 讲 是 服务 器 租赁 并 提供 基础 设施 外 
包 服 务 。 就 比如 我 们 用 的 水 和 电 一 样 ， 我 们 不 会 自己 去 引入 自来水 和 发 电 ， 而 是 直 
接 从 自来水 公司 和 电网 公司 购 入 ， 并 根据 实际 使 用 付费 。 


EC2 申 正 对 IT 的 改变 是 硬件 的 虚拟 化 (更 细 粒 度 的 虚拟 化 ) ， 而 EC2 给 用 户 带 来 了 
以 下 五 个 好 处 : 


e 降低 劳动 力 成 本 : 减少 了 企业 本 身 雇佣 | 和 T 人 员 的 成 本 

e 降低 风险 : 不 用 再 像 自己 运 维 物理 机 那样 ， 担 心 各 种 意外 风险 ，EC2 有 主机 损 
坏 ， 再 申请 一 个 就 好 了 。 

e 降低 基础 设施 成 本 : 可 以 按 小 时 、 周 、 ARAT ANEGA 

e 扩展 性 : 不 必 过 早 的 预期 基础 设施 采购 ， 因 为 通过 云 厂 商 可 以 很 快 的 获取 。 

e 节约 时 间 成 本 : 快速 的 获取 资源 开展 业务 实验 。 


以 上 说 了 是 laaS 或 者 说 基础 设施 外 包 的 好 处 ， 当 然 其 中 也 有 次 端 ， 我 们 将 在 后 面 讨 


ie o 


以 上 是 AWS 为 代表 的 公有 云 laaS， 还 有 使 用 OpenStack 构 建 的 私有 云 也 能 够 提供 
laaS 能 力 。 


PaaS 


PaaS (Platform as a Service) P» 建 在 laaS 之 上 的 一 种 平台 服务 ， 提 供 操作 系统 
安装 、 监 控 和 服务 发 现 等 功能 ， 只 需要 部 署 自 己 的 应 用 即 可 ， 最 早 的 一 代 是 
Heroku。Heroko 是 商业 的 PaaS ， ee ee NU Foundry » fl È 
可 以 基于 它 来 构建 私有 PaaS， 如 果 同 时 使 用 公有 云 和 私有 云 ， 如 果 能 在 两 者 之 间 
构建 一 个 统一 的 PaaS， 那 就 是 “混合 云 " 了 。 


在 PaaS 上 最 广泛 使 用 的 技术 就 要 数 docker 了 ， 因 为 使 用 容器 可 以 很 清晰 的 描述 应 
用 程序 ， 并 保证 环境 一 致 性 。 管 理 云 上 的 容器 ， 可 以 称 为 是 CaaS (Container as a 
Service) > 如 GCE (Google Container Engine) 。 也 可 以 基于 
Kubernetes、Mesos 这 类 开源 软件 构件 自己 的 CaaS， 不 论 是 直接 在 laaS 构 建 

基于 PaaS 。 


PaaS 是 对 软件 的 一 个 更 高 的 抽象 层次 ， 已 经 接触 到 应 用 程序 的 运行 环境 本 身 ， 可 
以 由 开发 者 自 定义 ， 而 不 必 接 触 更 底层 的 操作 系统 。 


Serverless 的 定义 


Serverless 不 如 |aaS 和 和 PaaS 那么 好 理解 ， 因 为 它 通常 包含 了 两 个 领域 
BaaS (Backend as a Service) 和 FaaS "bes as a Service) » 


BaaS 


理解 Serverless 


BaaS (Backend as a Service) 后 端 即 服务 ， 一 般 是 一 个 个 的 API 调 用 后 端 或 别人 
已 经 实现 好 的 程序 逻辑 ， 比 如 身份 验证 服务 Auth0， 这 些 BaaS 通 常会 用 来 管理 数 
据 ， 还 有 很 多 公有 云 上 提供 的 我 们 常用 的 开源 软件 的 商用 服务 ， 比 如 亚 马 进 的 RDS 
可 以 替代 我 们 自己 部 署 的 MySQL， 还 有 各 种 其 它 数据 库 和 存储 服务 。 


FaaS 


FaaS (Functions as a Service) 函数 即 服务 ，FaaS 是 无 服务 器 计算 的 一 种 形式 ， 
当前 使 用 最 广泛 的 是 AWS 的 Lambada。 


现在 当 大 家 讨论 Serverless 的 时 候 首 先 想 到 的 就 是 FaaS， 有 点 其 器 省 上 了 。FaaS 
本 质 上 是 一 种 事件 驱动 的 由 消息 触发 的 服务 ，FaaS 供 应 商 一 般 会 集成 各 种 同步 和 异 
步 的 事件 源 ， 通 过 订阅 这 些 事件 源 ， 可 以 突 发 或 者 定期 的 触发 函数 运行 。 


host/VM/container 





图 片 -服务 端 软件 的 运行 环境 


传统 的 服务 器 端 软件 不 同 是 经 应 用 程序 部 署 到 拥有 操作 系统 的 虚拟 机 或 者 容器 中 ， 
一 般 需 要 长 时 间 驻 留 在 操作 系统 中 运行 ， 而 FaaS 是 直接 将 程序 部 署 上 到 平台 上 即 
可 ， 当 有 事件 到 来 时 触发 执行 ， 执 行 完 了 就 可 以 卸载 掉 。 
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FaaS platform 





图 片 - FaaS 应 用 架构 
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两 者 都 为 我 们 的 计算 资源 提供 了 弹性 的 保障 ，BaaS 其 实 依然 是 服务 外 包 ， 而 FaaS 
使 我 们 更 加 关注 应 用 程序 的 逻辑 ， 两 者 使 我 们 不 需要 关注 应 用 程序 所 在 的 服务 器 ， 
但 实际 上 服务 器 依然 是 客观 存在 的 。 


当 我 们 将 应 用 程序 迁移 到 容器 和 虚拟 机 中 时 ， 其 实 对 于 应 用 程序 本 身 的 体系 结构 并 
没有 多 少 改 变 ， 只 不 过 有 些 流程 和 规定 需要 遵守 ， 上 比如 12 因 素 应 用 守则 ， 但 是 
Serverlss 对 应 用 程序 的 体系 结构 来 说 就 是 一 次 颠覆 了 ， 通 常 我们 需要 考虑 事件 驱动 
模型 ， 更 加 细 化 的 不 熟 形式 ， 以 及 在 FaaS 组 件 之 外 保持 状态 的 需求 。 


Serverless 应 用 
我 们 以 一 个 游戏 应 用 为 例 ， 来 说 明 什 么 是 serverless 应 用 。 


一 款 移动 端 游戏 至 少 包含 如 下 几 个 特性 : 


e 移动 端 友 好 的 用 户 体 验 


e 用 户 管理 和 权限 认证 
e 关卡 、 升 级 等 游戏 逻辑 ， 游 戏 排行 ， 玩 家 的 等 级 、 任 务 等 信息 


传统 的 应 用 程序 架构 可 能 是 这 样 的 : 


2-98 08 


Native Java application Relational 
mobile app server database 





图 片 - 传统 应 用 程序 架构 


e 一 个 app 前 端 ，iOS 后 者 安 卓 
e 用 Java 写 的 后 端 ， 使 用 JBoss 或 者 Tomcat 做 server 运 行 
e 使 用 关系 型 数据 库存 储 用 户 数据 ， 如 MySQL 


这 样 的 架构 可 以 让 前 端 十 分 轻便 ， 不 需要 做 什么 应 用 逻辑 ， 只 是 负责 泻 梁 用 户 界 
面 ， 将 请 求 通过 HTTP 发 送 给 后 端 ， 而 所 有 的 数据 操作 都 是 有 由 后 端的 Java 程 序 来 
完成 的 。 

这 样 的 架构 开发 起 来 比较 容易 ， 但 是 维护 起 来 确 十 分 复杂 ， 前 端 开 发 、 后 端的 开发 
都 需要 十 分 专业 的 人 人员、 环境 的 配置 ， 还 要 有 人 专门 维护 数据 库 、 应 用 的 更 新 和 升 
级 。 


Native 
mobile app 


oe 


图 片 - Serverless3 14 


而 在 Serverless 架 构 中 ， 我 们 不 再 需要 在 服务 器 端 代码 中 存储 任何 会 话 状态 ， 而 是 
直接 将 它们 存储 在 NoOSQL 中 ， 这 样 将 使 应 用 程序 无 状态 ， 有 助 于 弹性 扩展 。 前 端 可 
以 直接 利用 BaaS 而 减少 后 端的 编码 需求 ， 这 样 架 构 的 本 质 上 是 减少 了 应 用 程序 开 
发 的 人 力 成 本 ， 降 低 了 自己 维护 基础 设施 的 风险 ， 而 且 利用 云 的 能 力 更 便于 扩展 和 
快速 迭代 。 


Serverless 的 优势 


在 最 前 面 我 们 提 到 了 使 用 laaS 给 我 们 带 来 了 五 点 好 处 ，FaaS 当 然 也 包括 了 这 些 好 
处 ， 但 是 它 给 我 们 带 来 的 最 大 的 好 处 就 是 多 快 好 省 。 减 少 从 概念 原型 到 实施 的 等 待 
时 间 ， 比 自己 维护 服务 更 省 钱 。 


降低 人 力 成 本 


不 需要 再 自己 维护 服务 器 ， 操 心服 务 器 的 各 种 性 能 指标 和 资源 利用 率 ， 而 是 关心 应 
用 程序 本 身 的 状态 和 逻辑 。 而 且 Serverless 应 用 本 身 的 部 署 也 十 分 容易 ， 我 们 只 要 
上 传 基本 的 代码 但 愿 ， 例 如 Javascript 或 Python 的 源 代码 的 zip 文 件 ， 以 及 基于 JVM 
的 语言 的 纯 JAR 文 件 。 不 需 使 用 Puppet、Chef、Ansible 或 Docker 来 进行 配置 管 


Ws MART E ee dius 
使 用 量 、CPU 使 用 率 等 底层 和 长 期 的 指标 信息 ， 而 是 监控 应 用 程序 本 身 的 度量 ， 这 
将 更 加 直观 和 有 效 。 


在 此 看 来 有 人 可 能 会 提出 “NoOps” 的 说 法 ， 其 实 这 是 不 存在 的 ， 只 要 有 应 用 存在 的 
一 天 就 会 有 Ops， 只 是 人 员 的 角色 会 有 所 转变 ， 部 署 将 变 得 更 加 自动 化 ， 监 控 将 更 
加 面向 应 用 程序 本 身 ， 更 底层 的 运 维 依然 需要 专业 的 人 员 去 做 。 


降低 风险 


对 于 组 件 越 多 越 复杂 的 系统 ， 出 故障 的 风险 就 越 大 。 我 们 使 用 BaaS 或 FaaS 将 它们 
外 包 出 去 ， 让 专业 人 员 来 处 理 这 些 故 障 ， 有 时 候 比 我 们 自己 来 修复 更 可 靠 ， 利 用 专 
业 人 员 的 知识 来 降低 停机 的 风险 ， 缩 短 故障 修复 的 时 间 ， 让 我 们 的 系统 稳定 性 更 


e 


m] e 
减少 资源 开销 


我 们 在 申请 主机 资源 一 般 会 评估 一 个 峰值 最 大 开销 来 申请 资源 ， 往 往 导 致 过 度 的 配 
置 ， 这 意味 着 即使 在 主机 闲置 的 状态 下 也 要 始终 支付 峰值 容量 的 开销 。 对 于 某 些 应 
用 来 说 这 是 不 得 已 的 做 法 ， 比 如 数据 库 这 种 很 难 扩展 的 应 用 ， 而 对 于 普通 应 用 这 就 
显得 不 太 合 理 了 ， 虽 然 我 们 都 觉得 即使 浪费 了 资源 也 比 当 峰 值 到 来 时 应 用 程序 因为 
资源 不 足 而 挂 掉 好 。 


解决 这 个 问题 最 好 的 办 法 就 是 ， 不 计划 到 底 需 要 使 用 多 少 资源 ， 而 是 根据 实际 需要 
来 请 求 资源 ， 当 然 前 提 必 须 是 整个 资源 池 是 充足 的 (公有 云 显 然 更 适合 ) © RUE 
用 时 间 来 付费 ， 根 据 每 次 申请 的 计算 资源 来 付费 ， 让 计 费 的 粒度 更 小 ， 将 更 有 利于 
降低 资源 的 开销 。 这 是 对 应 用 程序 本 身 的 优化 ， 例 如 让 每 次 请 求 耗 时 更 短 ， 让 每 次 
消耗 的 资源 更 少将 能 够 显著 节省 成 本 。 


增加 缩放 的 灵活 性 


以 AWS Lamba 为 例 ， 当 平台 接收 到 第 一 个 触发 函数 的 事件 时 ， 它 将 启动 一 个 容器 
来 运行 你 的 代码 。 如 果 此 时 收 到 了 新 的 事件 ， 而 第 一 个 容器 仍 在 处 理 上 一 个 事件 ， 
平台 将 启动 第 二 个 代码 实例 来 处 理 第 二 个 事件 。AWS lambad 的 这 种 自动 的 零 管理 
水 平 缩放 ， 将 持续 到 有 足够 的 代码 实例 来 处 理 所 有 的 工作 负载 。 


但 是 ，AWS 仍 然 只 会 向 您 收取 代码 的 执行 时 间 ， 无 论 它 需 要 启动 多 少 个 容器 实例 要 
满足 你 的 负载 请 求 。 例 如 ， 假 设 所 有 事件 的 总 执行 时 间 是 相同 的 ， 在 一 个 容器 中 按 
顺序 调用 Lambda 100 次 与 在 100 个 不 同 容 器 中 同时 调用 100 次 Lambda 的 成 本 是 一 


样 的 。 当 然 AWS Lambada 也 不 会 无 限制 的 扩展 实例 个 数 ， 如 果 有 人 对 你 发 起 了 
DDos 攻 击 怎 么 办 ， 那 么 不 就 会 产生 高 兄 的 成 本 吗 ?AWS 是 有 默认 限制 的 ， 默 认 执 
fTLambada $ ZG X 3t Z 2€ 1000 © 


a 48 | A A 
小 团队 的 开发 人 员 正 可 以 在 几 天 之 内 从 头 开 始 开 发 应 用 程序 并 部 署 到 生产 。 使 用 短 
而 简单 的 元 数 和 事件 来 粘 合 强大 的 驱动 数据 存储 和 服务 的 APl。 完 成 的 应 用 程序 具 
有 高 度 可 用 性 和 可 扩展 性 ， 利 用 座高 ， 成 本 低 ， 部 署 速度 快 
以 docker 为 代表 的 容器 技术 仅仅 是 缩短 了 应 用 程序 的 迭代 周期 ， 而 serverless 技 术 


是 直接 缩短 了 创新 周期 ， 从 概念 到 最 小 可 行 性 部 署 的 时 间 ， 让 初级 开发 人 员 也 能 在 
很 短 的 时 间 内 完成 以 前 通常 要 经 验 丰 富 的 工程 师 才 能 完成 的 项 目 。 


Serverless $4 4 & 


我 们 知道 没有 十 全 十 美的 技术 ， 在 说 了 serverless 的 那么 多 优势 之 后 ， 我 们 再 来 探 
讨 以 下 serverless 的 劣势 ， 或 者 说 局 限 性 和 适用 场景 。 


状态 管理 


要 想 实 现 自 由 的 缩放 ， 无 状态 是 必须 的 ， 而 对 于 有 状态 的 服务 ， 使 用 serverless 这 
就 趟 失 了 灵活 性 ， 有 状态 服务 需要 与 存储 交互 就 不 可 避免 的 增加 了 延迟 和 复杂 性 。 


延迟 


应 用 程序 中 不 同 组 件 的 访问 延迟 是 一 个 大 问题 ， 我 们 可 以 通过 使 用 专 有 的 网 络 协 
议 、RPC 调 用 、 数 据 格 式 来 优化 ， 或 者 是 将 实例 放 在 同一 个 机 架 内 或 同一 个 主机 实 
例 上 来 优化 以 减少 延迟 。 


而 Serverless 应 用 程序 是 高 度 分 布 式 、 低 耦合 的 ， 这 就 意味 着 延迟 将 始终 是 一 个 问 
题 ， 单 纯 使 用 serverless 的 应 用 程序 是 不 太 现 实 的 。 


本 地 测试 


Serverless 应 用 的 本 地 测试 困难 是 一 个 很 闵 手 的 问题 。 虽 然 可 以 在 测试 环境 下 使 用 
各 种 数据 库 和 消息 队列 来 模拟 生产 环境 ， 但 是 对 于 无 服务 应 用 的 集成 或 者 端 到 端 测 
试 尤其 困难 ， 很 难 在 本 地 模拟 应 用 程序 的 各 种 连接 ， 并 与 性 能 和 缩放 的 特性 结合 起 
来 测试 ， 并 且 serverless 应 用 本 身 也 是 分 布 式 的 ， 简 单 的 将 无 数 的 FaaS 和 BaaS 组 件 
粘 合 起 来 也 是 有 挑战 性 的 。 
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FaaS (Functions as a Service) 函数 即 服务 ，FaaS 是 无 服务 器 计算 的 一 种 形式 ， 
当前 使 用 最 广泛 的 是 AWS 的 Lambada。 


现在 当 大 家 讨论 Serverless 的 时 候 首 先 想到 的 就 是 FaaS， 有 点 其 器 尘 上 了 。FaaS 
本 质 上 是 一 种 事件 驱动 的 由 消息 触发 的 服务 ，FaaS 供 应 商 一 般 会 集成 各 种 同步 和 弄 
步 的 事件 源 ， 通 过 订阅 这 些 事 件 源 ， 可 以 突 发 或 者 定期 的 触发 函数 运行 。 


当前 开源 的 FaaS 框 架 大 部 分 都 是 基于 Kuberentes 来 实现 的 ， 例 如 : 


e faas-netes - Enable Kubernetes as a backend for Functions as a Service 
(OpenFaaS) https://github.com/alexellis/faas 

e ín - The container native, cloud agnostic serverless platform. http://fnproject.io 

funktion - a CLI tool for working with funktion https://funktion.fabric8.io/ 

e fx - Poor man's serverless framework based on Docker, Function as a 
Service with painless. 


e lronFunctions - IronFunctions - the serverless microservices platform. 
http://iron.io 

e kubeless - Kubernetes Native Serverless Framework hitp://kubeless.io 

e nuclio - High-Performance Serverless event and data processing platform 

e OpenFaaS - OpenFaaS - Serverless Functions Made Simple for Docker & 
Kubernetes https://blog.alexellis.io/introducing-functions-as-a-service/ 

e OpenWhisk - Apache OpenWhisk (Incubating) is a serverless, open source 
cloud platform that executes functions in response to events at any scale. 


关于 整个 Cloud Native 7& ^E. A » i$ 4 A awesome-cloud-native ° 
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OpenFaaS 一 款 高 人 气 的 开源 的 faas 框 架 ， 可 以 直接 在 Kubernetes 上 和 运行， 也 可 以 
基于 Swarm 或 容器 运行 。 


在 Kubernetes 上 部 署 OpenFaaS 十 分 简单 ， 用 到 的 镜像 如 下 : 


e functions/faas-netesd:0.3.4 

e functions/gateway:0.6.14 

e functions/prometheus:latest-k8s 
e functions/alertmanager:latest-k8s 


这 些 镜像 都 存储 在 DockerHub 上 。 


OpenFaaS 的 架构 如 下 图 : 


Functions as a Service 


Function Watchdog 


A Swarm Kubernetes 
4 docker 


图 片 - OpenFaaS2 4 


API Gateway 





Prometheus 


id 





部 着 


参考 Deployment guide for Kubernetes 部 署 DpenFaaS ° 
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如 果 您 的 Kuberentes 集 群 可 以 访问 DockerHub 那 么 直接 使 用 官方 提供 的 YAML 文 件 
即 可 。 


YAML 文 件 见 官方 仓库 : https://github.com/openfaas/faas-netes 


部 署 同步 请 求 
一 共用 到 了 三 个 YAML 文 件 : 


e faas.yml 
e monitoring.yml 
e rbac.yml 


访问 端口 
服务 TCP 端 口 


API Gateway/UI 31112 
Prometheus 31119 


OpenFaaS 安 装 好 后 会 启动 一 个 Prometheus， 使 用 31119 端 口 ， 通 过 任意 一 个 node 
可 以 访问 Ul : http://172.20.0.113:31119 





Prometheus Time Series Colle x 


é C Q 01220033 7 1 7 k 7 f t & ıı t DONIA RAOT : 


BR Tue, 19 Dec 2017 14:09:42 GMT 
Invocation_total: 


gateway. function | : 288 


code: 200 
function name: nodoinfo. 
Instance: 10.254.178.229:8080 
Job: gateway 








gateway. function Invocation total(code-"500" function names"qrcode-go" instance="10.254.178.229:8080" Job-"gateway") 
gateway. function Invocation total(code-"500" function names"nodeinfo" instance="10.254.178.229:8080" job="gateway"} 
gateway function Invocation total(codez"200" function names"nodeinfo" instances" 10.254.178.229:8080" job="gateway"} 
gateway function Invocation total(code-"200" function names"hubstats" instance-"10.254.178.229:8080" job-"gateway") 





Remove Graph 


图 片 - OpenFaaS Prometheus 


在 这 里 可 以 看 到 函数 的 运行 情况 。 


同时 OpenFaaS 还 提供 了 Dashboard ， 需 要 我 们 自己 向 Grafana 中 配置 Prometheus 
数据 源 后 导入 ，JSON 配 置 见 : https://grafana.com/dashboards/3526， 可 以 下 载 后 
直接 导入 到 Grafana 中 。 





*^ Grafana - Original Open FaaS x 


€ CO © 172.20.0.113:808 prox kube-system/se t j jl fa = ar ooa Aha : 


@2 Original Open FaaS Dashboard - @ M % € zoomout > © Last 15 minutes 


Function rate Replica scaling 


0 07 
21:58 22:00 22:02 22:04 22:06 21:58 22:00 22:02 22:04 
hubstats 200 nodeinfo 200 一 nodeinfo 500 qrcode-go 500 hubstats nodeinfo 一 qrcode-go 


Total requests - 200 OK Execution duration (s) 


No datapoints @ 


275 


+ ADD ROW 





EH - OpenFaas Grafana s 1€ 


OpenFaaS 的 使 用 


OpenFaaS 提 供 了 便捷 的 Ul， 在 部 署 完 成 后 就 可 以 通过 NodePort 方 式 访问 。 


使 用 API Gateway 的 端口 ， 通 过 任意 一 个 node 可 以 访问 
UI 5 http://172.20.0.113:31112 


OpenFaaS 快 速 入 门 指南 


图 172.20.0.113:31112/ui/ x 


€ co | © Not Secure | 172.20.0.113:31112/ui/ Qaxi9048®@ Qo i 





FROM STORE MANUALLY 


Q Search for Function 


Inception 
This is a forked version of the work by Magnus Erik Hvass Pedersen - it has been re-packaged as an OpenFaaS serverless function. 


mememachine 
Turn any image into a meme. 


Figlet 
OpenFaaS Figlet image. This repository comes with the blog post http://jmkhael.io/create-a-serverless-ascii-banner-with-faas/ 


Nodelnfo 
Get info about the machine that you're deployed on. Tells CPU count, hostname, OS, and Uptime 


Left-Pad 
left-pad on OpenFaaS 


Dockerhub Stats 
Golang function gives the count of repos a user has on the Docker hub 


o 
© 
6 
© 
e 
也 


QR Code Generator - Go 
QR Code generator using Go 


E 


CLOSE DIALOG DEPLOY 








& A - OpenFaas Dashboard 


其 中 已 经 内 置 了 一 些 函 数 应 用 可 供 我 们 试用 ， 还 可 以 创建 自己 的 函数 。 


比如 内 置 的 NodeInfo 应 用 ， 可 以 获取 该 应 用 所 部 署 到 的 主机 的 信息 ， 如 下 图 : 
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图 172.20.0.113:31112/ui/ x 


€ CQ (Y |O Not Secure | 172.20.0.113:31112/u 


OpenFaaS Portal a 


D li 
> ] Deploy New Function 1 0 


mage 
functions/nodeinfo:latest 


hubstats Invoke function 


INVOKE 


nodeinfo 
@ Text © JSON (©) Download 


Respor ound-tri 
200 0.174 
Hostname: nodeinfo-699d4bdcbc-s2jfz 

Platform: linux 

Arch: x64 


CPU count: 40 
Uptime: 1223867 


图 片 - Nodelnfo 执 行 结果 


QrigOaOmagrs : 


注意 : 有 一 些 js 和 css 文 件 需要 翻 墙 才 能 访问 ， 否 则 页 面 将 出 现 格式 错误 。 


命令 行 工具 


OpenFaaS 提 供 了 命令 行 工具 faas-cli， 使 用 该 工具 可 以 管理 DODpenFaaS 中 的 函数 。 


可 以 到 openfaas GitHub release 下 载 对 应 操作 系统 的 命令 行 工 具 。 或 者 使 用 下 面 的 


命令 安装 最 新 faas-cli : 


curl -SL cli.openfaas.com | sudo sh 


faas-cli 4-3 8] 
下 面 是 faas-cli 命令 的 几 个 使 用 案例 。 


获取 当前 部 署 的 函数 状态 : 


faas-cli list --gateway http://172.20.0.113:31112 


Function Invocations Replicas 
hubstats 9 1 
nodeinfo 9 1 

调用 有 函数 nodeinfo : 


echo ""|faas-cli invoke nodeinfo --gateway http://172.20.0.113:3 
1112 
Hostname: nodeinfo-699d4bdcbc-s2jfz 


Platform: linux 
Arch: x64 


CPU count: 40 
Uptime: 1728200 


OpenFaaS 的 命令 行 工 具 faas-cli 的 详细 使 用 说 明 
JL : https://github.com/openfaas/faas-cli 


Deployment guide for Kubernetes - GitHub openfaas/faas 
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The Birth of an Edge Orchestrator — Cloudify Meets Edge Computing 
K8s(Kubernetes) and SDN for Multi-access Edge Computing deployment 
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入 
人 工人 智能 
Kubernetes 在 人 工 智 能 领域 的 应 用 。 


TBD 


e kubeflow - Kubernetes 机 器 学 习 工 具 箱 
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开发 指南 说 明 


讲解 如 何在 原生 Kubernetes 的 基础 上 做 定制 开发 。 
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SIG 和 工作 组 


SIG 和 工作 组 


Kubernetes 的 社区 是 以 SIG (Special Interest Group 特别 兴趣 小 组 ) 和 工作 组 的 形 
式 组 织 起 来 的 ， 每 个 工作 组 都 会 定期 召开 视频 会 议 。 


所 有 的 SIG 和 工作 组 都 使 用 slack 和 邮件 列表 沟通 。 


Multi-cluster 





Network 










OpenStack 
Architecture 


auth 


CLI 
Cluster Lifecycle 
Cluster Ops 


Contributor Experence 





Instrumentation 


A A - Kubernetes SIG 


主要 SIG 列 表 


e api-machinery : 所 有 API 级 别 的 功能 ， 包 括 了 API server、API 注 册 和 发 现 、 
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通用 的 API CRUD 语 义 ， 准 入 控制 ， 编 码 /解码 ， 转 换 ， 默 认 值 ， 持 久 化 层 
(etcd) ，OpenAPI， 第 三 方 资 源 ， 垃 圾 手机 和 客户 端 库 的 方方面面 。 

aws : 如 何在 AWS 上 支持 和 使 用 kubernetes 。 

apps : 在 kubernetes 上 部 署 和 运 维 应 用 程序 。 关 注 开 发 者 和 DevOps 在 

kubernetes 上 运行 应 用 程序 的 体验 。 

architecture : 维持 kubernetes 在 架构 设计 上 的 一 致 性 和 原则 。 

auth : kubernetes 的 认证 授权 、 权 限 管 理 和 安全 性 策略 。 

autoscaling : 集群 的 自动 缩放 ，pod 的 水 平和 垂直 自动 缩放 ，pod 的 资源 初始 

化 ，pod 监 控 和 指标 收集 等 主题 。 

azure : 如 何在 Azure 上 支持 和 使 用 kubernetes 。 

big-data : 在 kubernetes 上 部 署 和 运行 大 数据 应 用 ， 如 Spark、Kafka、 

Hadoop、Flink、Storm 等 。 

CLI : kubectl 和 相关 工具 。 

cluster-lifecycle : 部 署 和 升级 kubernetes 集 群 。 

cluster-ops : 促进 kubernetes 集 群 本 身 的 可 操作 性 和 集群 间 的 互 操作 性 ， 使 不 
同 的 运营 商 之 间 协 调 一 致 。 

contributor-experience : 维持 良好 的 开发 者 社区 。 

docs : 文档 ， 流 程 和 出 版 物 。 

GCP : 在 Google Cloud Platform 上 使 用 kubernetes。 

instrumentation : 集群 可 观测 性 的 最 佳 实践 ， 包 括 指标 设置 、 日 志 收 集 、 事 

件 等 。 

multicluster : 多 kubernetes 集 群 的 用 例 和 工具 。 

network : kubernetes 集 群 的 网 络 。 

node : node 节 点 、kubelet 。 

onprem : 在 非 云 供应 商 的 环境 下 运行 kubernetes， 例 如 on premise、 裸 机 等 

环境 。 

openstack : 协调 跨 OpenStack 和 Kubernetes 社 区 的 努力 。 

product-management : 侧重 于 产品 管理 方面 。 

release : 发 布 、 PR 和 bug 提 交 等 。 

scalability : 负责 回答 可 伸缩 性 相关 的 问题 。 

scheduling : 资源 调度 。 

service-catalog : 为 CNCF service broker 和 Kubernetes broker 实 现 开发 

API ° 

storage : 存储 和 volume 插 件 。 

testing : 测试 。 

ui : 与 UI 相关 的 话题 。 


e windows : 在 kubernets 上 运 


HF 


2 fT Windows Server Container ° 


工作 组 列表 


App Def : 改进 AP| 中 的 声明 性 原 语 、 客 户 端 库 、 工 具 的 用 户 体 验 。 

Cloud Provider : 云 供 应 商工 作 组 。 

Cluster API : 定义 一 个 代表 Kubernetes 集 群 的 可 移植 API1。 API 将 包含 控制 平 
面 及 其 配置 和 底层 基础 设施 (节点 ， 节 点 池 等 ) e 

Container Identity : 确保 容器 能 够 获得 安全 的 身份 认证 并 与 外 部 连通 的 解决 
方案 。 

Kubeadm Adoption : 提高 kubeadm 工 具 的 采用 率 。 

Resource ManagementJ : 资源 隔离 和 提高 资源 利用 率 。 


详细 信息 请 参考 https://github.com/kubernetes/community/blob/master/sig-list.md 
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配置 Kubernetes 开 发 环境 


我 们 将 在 Mac 上 使 用 docker 环 境 编 译 kuberentes。 


KRR 


brew install gnu-tar 


Docker 环 境 ， 至 少 需要 给 容器 分 配 4G 内 存 ， 在 低 于 3G 内 存 的 时 候 可 能 会 编译 失 
败 。 


执行 编译 
切换 目录 到 kuberentes 源 码 的 根 目 录 下 执行 
./build/run.sh make 可 以 在 docker 中 执行 跨 平 台 编译 出 二 进 制 文件 。 


需要 用 的 的 docker 镜 像 : 


gcr.io/google containers/kube-cross:v1.7.5-2 


我 将 该 镜像 备份 到 时 速 云 上 了， 可 供 大 家 使 用 : 


index.tenxcloud.com/jimmy/kube-cross:vi1.7.5-2 


该 镜像 基于 Ubuntu 构建 ， 大 小 2.15G， 编 译 环境 中 包含 以 下 软件 : 


e Go1.7.5 

e etcd 

e protobuf 

e g++ 

e 其 他 golang 依 赖 包 


在 我 自己 的 电脑 上 的 整个 编译 过 程 大 概要 半 个 小 时 。 


编译 完成 的 二 进 制 文件 在 / output/local/go/bin/ 目录 下 。 
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本 地 分 布 式 开 发 环境 搭建 〈 使 用 Vagrant 和 
Virtualbox ) 


当 我 们 需要 在 本 地 开发 时 ， 更 希望 能 够 有 一 个 开 箱 即 用 又 可 以 方便 定制 的 分 布 式 开 
发 环境 ， 这 样 才 能 对 Kubernetes 本 身 和 应 用 进行 更 好 的 测试 。 现 在 我 们 使 
用 Vagrant 和 VirtualBox 来 创建 一 个 这 样 的 环境 。 


ad 需要 使 用 的 配置 文件 和 vagrantfile 请 
: https://github.com/rootsongjc/kubernetes-vagrant-centos-cluster 


注意 : kube-proxy 使 用 ipvs 模 式 。 


准备 环境 
需要 准备 以 下 软件 和 环境 : 


e 8G 以 上 内 存 

e Vagrant 2.0+ 

e Virtualbox 5.0 + 

e 提前 下 载 Kubernetes 的 安装 色 


集群 
我 们 使 用 ee 安装 包含 3 个 节点 的 kubernetes 集 群 ， 其 中 master 节 
点 同时 作为 node 节 
主机 , 
IP 名 组 件 


kube-apiserver ` kube-controller-manager ` kube- 
scheduler ` etcd ` kubelet ` docker ` flannel 


172.17.8.102  node2  kubelet ` docker ` flannel 
172.17.8.103  node3  kubelet ` docker ` flannel 


172.17.8.101 node1 


dk: 以 上 的 IP、 主 机 名 和 组 件 都 是 固定 在 这 些 节点 的 ， 即 使 销毁 后 下 次 使 用 
vagrant 重 建 依然 保持 不 变 。 


安装 完成 后 的 集群 包含 以 下 组 件 : 


e flannel 

e kubernetes dashboard 
e etcd (#7 x) 

e kubectl 


op A 
确保 安装 好 以 上 的 准备 环境 后 ， 执 行 下 列 命令 启动 kubernetes 集 群 : 


git clone https://github.com/rootsongjc/kubernetes-vagrant-cento 
s-cluster.git 

cd kubernetes-vagrant -centos-cluster 

vagrant up 


注意 : 克隆 完 Git 仓 库 后 ， 需 要 提前 下 载 kubernetes 的 压缩 包 到 kubenetes- 
vagrant-centos-cluster 目录 下 ， 包 括 如 下 两 个 文件 : 


e kubernetes-client-linux-amd64.tar.gz 
e kubernetes-server-linux-amd64.tar.gz 


如 果 是 首次 部 署 ， 会 自动 下 载 centos/7 的 box， 这 需要 花费 一 些 时 间 ， 另 外 每 个 
节点 还 需要 下 载 安 装 一 系列 软件 包 ， 整 个 过 程 大 概 需要 10 几 分 钟 。 


访问 kubernetes 和 集群 


访问 Kubernetes 集 群 的 方式 有 三 种 : 
通过 本 地 访问 


可 以 直接 在 你 自己 的 本 地 环境 中 操作 该 Kkubernetes 集 群 ， 而 无 需 登 录 到 虚拟 机 中 ， 
执行 以 下 步骤 : 


将 conf/admin.kubeconfig 文件 放 到 -/.kube/config 目录 下 即 可 在 本 地 使 
用 kubectl 命令 操作 集群 。 


在 虚拟 机 内 部 访问 
如 果 有 任何 问题 可 以 登录 到 虚拟 机 内 部 调试 : 


vagrant ssh nodel1 
sudo -i 
kubectl get nodes 


Kubernetes dashboard 
还 可 以 直接 通过 dashboard UI 来 访问 : https://172.17.8.101:8443 


可 以 在 本 地 执行 以 下 命令 获取 token 的 值 ( 需要 提前 安装 kubectl) 


kubectl -n kube-system describe secret "kubectl -n kube-system g 
et secret|grep admin-token|cut -d " " -f1°|grep "token:"|tr -s " 
"Icut -d " " -f2 


注意 : token 的 值 也 可 以 在 vagrant up 的 日 志 的 最 后 看 到 。 
Heapster 监 控 


创建 Heapster 监 控 : 


kubectl apply -f addon/heapster/ 


访问 Grafana 

使 用 Ingress 方 式 暴 露 的 服务 ， 在 本 地 /etc/hosts 中 增加 一 条 配置 : 
172.17.8.102 grafana.jimmysong.io 

访问 Grafana : http://grafana.jimmysong.io 


Traefik 


2h # Traefik ingress controllerfe 2$ Zeingress & X. : 


kubectl apply -f addon/traefik-ingress 


在 本 地 /etc/hosts 中 增加 一 条 配置 : 


172.17.8.102 traefik.jimmysong.io 


访问 Traefik UI : http://traefik.jimmysong.io 
EFK 


使 用 EFK 做 日 志 收 集 。 


kubectl apply -f addon/efk/ 


注意 : 运行 EFK 的 每 个 节点 需要 消耗 很 大 的 CPU 和 内 存 ， 请 保证 每 台 虚 拟 机 至 少 分 
配 了 4G 内 存 。 


清理 


vagrant destroy 
rm -rf .vagrant 


e Kubernetes handbook - jimmysong.io 

e duffqiu/centos-vagrant 

e kubernetes-vagrant-centos-cluster 

e vagrant & 7| — : Vagrant 的 配置 文件 vagrantfile 详 解 
e Vagrant 网 络 配 置 

e Kubernetes 1.8 kube-proxy 开启 ipvs 
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Kubernetes |, 


单元 测试 
单元 测试 仅 依赖 于 源 代码 ， 是 测试 代码 逻辑 是 否 符合 预期 的 最 简单 方法 。 


运行 所 有 的 单元 测试 


make test 


仅 测试 指定 的 package 


# 单个 backage 
make test WHAT=./pkg/api 
‘packages 
ne test WHAT=./pkg/{api, kubelet} 


或 者 ， 也 可 以 直接 用 go test 


go test -v k8s.io/kubernetes/pkg/kubelet 


仅 测试 指定 package 的 茶 个 测试 case 


# Runs TestValidatePod in pkg/api/validation with the verbose fl 
ag set 

make test WHAT=./pkg/api/validation KUBE_GOFLAGS="-v" KUBE_TEST_ 
ARGS='-run ATestValidatePod$' 


# Runs tests that match the regex ValidatePod|ValidateConfigMap 
in pkg/api/validation 

make test WHAT-./pkg/api/validation KUBE GOFLAGS-"-v" KUBE TEST 
ARGS="-run ValidatePod\|ValidateConfigMap$" 


或 者 直接 用 go test 


go test -v k8s.io/kubernetes/pkg/api/validation -run ^TestValida 
tePod$ 


并 行 测试 
并 行 测试 是 root out flakes 的 一 种 有 效 方法 : 


# Have 2 workers run all tests 5 times each (10 total iterations 


Js 
make test PARALLEL-2 ITERATION-5 


生成 测试 报告 


make test KUBE_COVER=y 


Benchmark 测 试 


go test ./pkg/apiserver -benchmem -run=XXX -bench=BenchmarkWatch 


集成 测试 
Kubernetes 集 成 测试 需要 安装 etcd (只 要 按照 即 可 ， 不 需要 局 动 ) ， 比 如 


hack/install-etcd.sh # Installs in ./third_party/etcd 
echo export PATH="\$PATH:$(pwd)/third_party/etcd" >> ~/.profile 
# Add to PATH 


集成 测试 会 在 需要 的 时 候 自动 启动 etcd 和 kubernetes 服 务 ， 并 运行 test/integration 里 
面 的 测试 。 
运行 所 有 集成 测试 


make test-integration # Run all integration tests. 
指定 集成 测试 用 例 


# Run integration test TestPodUpdateActiveDeadlineSeconds with t 
he verbose flag set. 

make test-integration KUBE GOFLAGS-"-v" KUBE_TEST_ARGS="-run ATe 
stPodUpdateActiveDeadlineSeconds$" 


End to end (e2e) 测 会 


End to end (e2e) 测试 模拟 用 户 行 为 操作 Kubernetes， 用 来 保证 Kubernetes 服 务 或 
集群 的 行为 完全 符合 设计 预期 。 


在 开启 e2e 测 试 之 前 ， 需 要 先 编译 测试 文件 ， 并 设置 
KUBERNETES PROVIDER (默认 为 gce) 


make WHAT='test/e2e/e2e.test' 
make ginkgo 
export KUBERNETES_PROVIDER=local 


启动 cluster， 测 试 ， 最 后 停止 cluster 


# build Kubernetes, up a cluster, run tests, and tear everything 


down 
go run hack/e2e.go -- -v --build --up --test --down 
仅 测试 指定 的 用 例 
go run hack/e2e.go -v -test --test_args='--ginkgo.focus=Kubect1l\ 


sclientNsN[k8sN.ioN]NsKubectlNsrollingN-updateNsshouldNssupportN 
srolling\-update\sto\ssame\simage\s\[Conformance\]$' 


略 过 测试 用 例 


go run hack/e2e.go -- -v --test --test_args="--ginkgo.skip=Pods. 
*env 


并 行 测试 


# Run tests in parallel, skip any that must be run serially 
GINKGO_PARALLEL=y go run hack/e2e.go --v --test --test_args="--g 
inkgo.skip=\[Serial\]" 


# Run tests in parallel, skip any that must be run serially and 
keep the test namespace if test failed 

GINKGO_PARALLEL=y go run hack/e2e.go --v --test --test_args="--g 
inkgo.skip=\[Serial\] --delete-namespace-on-failure=false" 


清理 测试 


go run hack/e2e.go -- -v --down 


有 用 的 -ctl 


# -ctl can be used to quickly call kubectl against your e2e clus 
ter. Useful for 

# cleaning up after a failed test or viewing logs. Use -v to avo 
id suppressing 

# kubectl output. 

go run hack/e2e.go -- -v -ctl='get events' 

go run hack/e2e.go -- -v -ctl='delete pod foobar' 


Fedaration e2e 22) iA, 


export FEDERATION=true 

export E2E_ZONES="us-centrali-a us-centrali-b us-centrali-f" 
# or export FEDERATION PUSH REPO BASE-"quay.io/colin hom" 
export FEDERATION PUSH REPO BASE-"gcr.io/$(GCE PROJECT NAMEj" 








# build container images 
KUBE RELEASE RUN TESTS-n KUBE FASTBUILD-true go run hack/e2e.go 
-- -v -build 


# push the federation container images 
build/push-federation-images.sh 


# Deploy federation control plane 
go run hack/e2e.go -- -v --up 


# Finally, run the tests 
go run hack/e2e.go -- -v --test --test_args="--ginkgo.focus=\[Fe 
ature:Federation\]" 


# Don't forget to teardown everything down 
go run hack/e2e.go -- -v --down 


可 以 用 cluster/log-dump.sh «directory» 方便 的 下 载 相 关上 日 志 ， 帮 助 排查 测 
试 中 碰 到 的 问题 。 


Node e2e7!| is 


Node e2e 仅 测试 Kubelet 的 相关 功能 ， 可 以 在 本 地 或 者 集群 中 测试 


export KUBERNETES_PROVIDER=local 

make test-e2e-node FOCUS="InitContainer" 

make test e2e node TEST_ARGS="--experimental-cgroups-per-qos=tru 
e" 


补充 说 明 
借助 kubectl 的 模版 可 以 方便 获取 想 要 的 数据 ， 比 如 查询 某 个 container 的 镜像 的 方法 


为 


kubectl get pods nginx-4263166205-ggst4 -0 template '--template= 
{{if (exists . "status" "containerStatuses")}}{{range .status.co 
ntainerStatuses}}{{if eq .name "nginx"}}{{.image}}{{end}}{{end}} 
{{end}}' 


kubernetes | iX 1 £ #test-infra 


test-infra 是 由 kubernetes 官 方 开源 的 测试 框架 ， 其 中 包括 了 Kubernetes 测 试 工 具 集 
和 测试 结果 展示 。 下 图 展示 了 test-infra 的 架构 : 


单元 测试 和 集成 测试 








update PR status 
comment failures 















create ProwJob 


eal 
Kubernetes 
API Server 


start Pod 





Sinker 
deletes old 
pods/ProwJobs 






publish 
Btarted.json, finished json, 
build-log.txt, artifacts/ 





Last updated 2017-07-13 


图 片 - test-infra 架 构图 (BARA EF GitHub) 


该 测试 框架 主要 是 丨 多 Google 公 有 云 做 的 ， 支 持 kubernetes1.6 以 上 版 本 的 测试 。 


?F JUhttps://github.com/kubernetes/test-infra ° 


参考 文档 


e Kubernetes testing 
e End-to-End Testing 
e Node e2e test 

e How to write e2e test 
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e Coding Conventions 
e https://github.com/kubernetes/test-infra 
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i$ Pl kubernetes 4% A JU T JLA Zr X : 


方式 


Kubernetes 
dashboard 


kubectl 


client-go 


client- 
python 


Java client 


特点 


直接 通过 Web UI 进 行 操作 ， 简 单 直接 ， 可 定制 化 程度 
K 


=> 


PARTE ^ AE ， 但 是 比较 复杂 ， 适 合 对 其 进 
HGH «RC 4A 能 ， 版 本 适 配 最 好 


pe iy et 代码 中 抽 离 出 来 的 客户 端 包 ， 简 单 易 
用 ， 但 需要 小 心 区 分 kubernetes 的 API 版 本 


33» 


python € P 3& > kubernetes-incubator 


fabric8 t? $ —#8 > * kubernetes£$java € P 35 


下 面 ， 我 们 基于 client-go， 对 Deployment 升 级 镜像 的 步骤 进行 了 定制 ， 
传递 一 个 Deployment 的 名 字 、 应 用 容器 名 和 新 image 名 字 的 方式 来 升级 。 代 码 和 使 
用 方式 见 https://github.com/rootsongjc/kubernetes-client-go-sample 。 


kubernetes-client-go-sample 


代码 如 下 


package main 


import ( 


n flag n 


"fmt n 
"os" 


"path/filepath" 


"k8s.io/apimachinery/pkg/api/errors" 

metavi "k8s.io/apimachinery/pkg/apis/meta/v1i" 
"k8s.io/client-go/kubernetes" 
"k8s.io/client-go/tools/clientcmd" 


) 


func main() { 
var kubeconfig *string 


redhat 


通过 命令 行 


if home := homeDir(); home != "" ( 
kubeconfig - flag.String("kubeconfig", filepath.Join(hom 
e, ".kube", "config"), "(optional) absolute path to the kubeconf 
ig file") 
} else { 
kubeconfig = flag.String("kubeconfig", "", "absolute pat 
h to the kubeconfig file") 


} 

deploymentName := flag.String("deployment", "", "deployment 
name") 

imageName :- flag.String("image", "", "new image name") 


appName := flag.String("app", "app", "application name") 


flag.Parse() 

if *deploymentName -- "" ( 
fmt.Println("You must specify the deployment name.") 
os.Exit(0) 


if *imageName -- "" ( 
fmt.Println("You must specify the new image name.") 
os.Exit(0) 

j 

// use the current context in kubeconfig 

config, err :- clientcmd.BuildConfigFromFlags("", *kubeconfi 

g) 

if err != nil { 

panic(err.Error()) 


j 


// create the clientset 
clientset, err :- kubernetes.NewForConfig(config) 
if err != nil { 
panic(err.Error()) 
} 
deployment, err := clientset.AppsVibeta1().Deployments("defa 
ult").Get(*deploymentName, metavi.GetOptions{}) 
if err != nil { 
panic(err.Error()) 
} 
if errors.IsNotFound(err) { 
fmt.Printf("Deployment not found\n") 
) else if statusError, isStatus :- err.(*errors.StatusError) 
; isStatus ( 
fmt.Printf("Error getting deployment%v\n", statusError.E 
rrStatus.Message) 


) else if err != nil { 
panic(err.Error()) 
} else { 
fmt.Printf("Found deployment\n") 
name := deployment .GetName() 
fmt.Println("name ->", name) 
containers := &deployment.Spec.Template.Spec.Containers 


found :- false 


for i := range *containers { 
C := *containers 
if c[i].Name == *appName { 
found = true 
fmt.Println("Old image ->", c[i].Image) 
fmt.Println("New image ->", *imageName) 
c[i].Image = *imageName 


j 


j 
if found -- false ( 
fmt.Println("The application container not exist in 
the deployment pods.") 


os.Exit(0) 
} 
_, err := clientset.AppsVibeta1().Deployments("default") 
.Update(deployment ) 
if err != nil { 
panic(err.Error()) 
} 
} 
} 
func homeDir() string { 
if h := os.Getenv("HOME"); h !- "" ( 
return h 
} 
return os.Getenv("USERPROFILE") // windows 
} 


我 们 使 用 kubeconfig 文件 认证 连接 kubernetes 集 群 ， 该 文件 默认 的 位 置 
是 $HOME/.kube/config ° 


该 代码 编译 后 可 以 直接 在 kubernetes 集 群 之 外 ， 任 何 一 个 可 以 连接 到 API servers 
机 器 上 运行 。 


编译 运行 


$ go get github.com/rootsongjc/kubernetes-client-go-sample 
$ cd $60PATH/Ssrc/github.com/rootsongjc/kubernetes-client-go-samp 
le 
$ make 
$ ./update-deployment-image -h 
Usage of ./update-deployment-image: 
-alsologtostderr 
log to standard error as well as files 
-app string 
application name (default "app") 
-deployment string 
deployment name 
-image string 
new image name 
-kubeconfig string 
(optional) absolute path to the kubeconfig file (default 
"/Users/jimmy/.kube/config") 
-log backtrace at value 
when logging hits line file:N, emit a stack trace 
-log dir string 
If non-empty, write log files in this directory 
-logtostderr 
log to standard error instead of files 
-stderrthreshold value 
logs at or above this threshold go to stderr 
-v value 
log level for V logs 
-vmodule value 
comma-separated list of pattern=N settings for file-filt 
ered logging 


BE] xj 
使 用 不 存在 的 image 更 新 


$ ./update-deployment-image -deployment filebeat-test -image ha 
rbor-001.jimmysong.io/library/analytics-docker-test:Build 9 
Found deployment 

name -» filebeat-test 

Old image -> harbor-001.jimmysong.io/library/analytics-docker-te 
st:Build 8 

New image -» harbor-001.jimmysong.io/library/analytics-docker-te 
st:Build 9 


2- & Deployment event ° 


$ kubectl describe deployment filebeat-test 


Name: filebeat-test 
Namespace: default 
CreationTimestamp: Fri, 19 May 2017 15:12:28 +0800 
Labels: k8s-app-filebeat-test 
Selector: k8s-app-filebeat-test 
Replicas: 2 updated | 3 total | 2 available | 2 unavailab 
le 
StrategyType: RollingUpdate 
MinReadySeconds: 0 
RollingUpdateStrategy: 1 max unavailable, 1 max surge 
Conditions: 

Type Status Reason 

Available True MinimumReplicasAvailable 

Progressing True ReplicaSetUpdated 
OldReplicaSets: filebeat-test-2365467882 (2/2 replicas create 
d) 
NewReplicaSet: filebeat-test-2470325483 (2/2 replicas created 
) 
Events: 

FirstSeen LastSeen Count From SubObjec 
tPath Type ReasoMessage 

2h 1m 3 {deployment-controller ) N 
ormal ScalingReplicaSet Scaled down replica set filebe 
at-test-2365467882 to 2 

1m 1m 1 {deployment-controller ) N 
ormal ScalingReplicaSet Scaled up replica set filebeat 
-test-2470325483 to 1 

1m 1m 1 {deployment-controller ) N 
ormal ScalingReplicaSet Scaled up replica set filebeat 


-test-2470325483 to 2 


可 以 看 到 老 的 ReplicaSet 从 3 个 replica 减 少 到 了 2 个 ， 有 2 个 使 用 新 配置 的 replica 不 可 
用 ， 目 前 可 用 的 replica 是 2 个 。 


这 是 因为 我 们 指定 的 镜像 不 存在 ， 查 看 Deployment 的 pod 的 状态 。 


$ kubectl get pods -1 k8s-app-filebeat-test 


NAME READY STATUS RE 

STARTS AGE 

filebeat-test-2365467882-4zwx8 2/2 Running 0 
33d 

filebeat-test-2365467882-rqskl 2/2 Running 0 
33d 

filebeat-test-2470325483-6vjbw 1/2 ImagePullBackOf fF 0 
4m 

filebeat -test-2470325483-gc14k 1/2 ImagePullBackOf fF 0 
4m 


我 们 可 以 看 到 有 两 个 pod 正 在 拉 取 image。 
还 原 为 原先 的 镜像 


将 image 设 置 为 原来 的 镜像 。 


$ ./update-deployment-image -deployment filebeat-test -image har 
bor-001.jimmysong.io/library/analytics-docker-test:Build 8 

Found deployment 

name -» filebeat-test 

Old image -> harbor-001.jimmysong.io/library/analytics-docker-te 
st:Build 9 

New image -» harbor-001.jimmysong.io/library/analytics-docker-te 
st:Build 8 


现在 再 查看 Deployment 的 状态 。 


$ kubectl describe deployment filebeat-test 


Name: filebeat-test 
Namespace: default 
CreationTimestamp: Fri, 19 May 2017 15:12:28 +0800 
Labels: k8s-app-filebeat-test 
Selector: k8s-app-filebeat-test 
Replicas: 3 updated | 3 total | 3 available | 0 unavailab 
le 
StrategyType: RollingUpdate 
MinReadySeconds: 0 
RollingUpdateStrategy: 1 max unavailable, 1 max surge 
Conditions: 

Type Status Reason 

Available True MinimumReplicasAvailable 

Progressing True NewReplicaSetAvailable 
OldReplicaSets: <none> 
NewReplicasSet: filebeat-test-2365467882 (3/3 replicas created) 
Events: 

FirstSeen LastSeen Count From SubObjec 
tPath Type ReasoMessage 

2h am 3 {deployment-controller } N 
ormal ScalingReplicaSet Scaled down replica set filebe 
at-test-2365467882 to 2 

8m 8m 1 {deployment-controller } N 
ormal ScalingReplicaSet Scaled up replica set filebeat 
-test-2470325483 to 1 

8m 8m 1 {deployment-controller } N 
ormal ScalingReplicaSet Scaled up replica set filebeat 
-test-2470325483 to 2 

2h 1m 3 {deployment-controller } N 
ormal ScalingReplicaSet Scaled up replica set filebeat 
-test-2365467882 to 3 

1m 1m 1 {deployment-controller } N 
ormal ScalingReplicaSet Scaled down replica set filebe 


at-test-2470325483 to 0 
M OOOO ëO 
可 以 看 到 available 的 replica 个 数 恢复 成 3 了 。 


其 实在 使 用 该 命令 的 过 程 中 ， 通 过 kubernetes dashboard 的 页 面 上 查看 Deployment 
的 状态 更 直观 ， 更 加 方便 故障 排查 。 


client-go 77 


例 


P 








三 kubernetes Deployments + CREATE 
Admin 
CPU usage Memory usage @ 
Namespaces 
Nodes 0.405. 7.33 Gi 
_ 0.360) @ 6.52 Gi 
Persistent Volumes $ oz $ soci 
8 gE 
Storage Classes 5 0.180 E 326Gi 
& 0.090 5 1.63 Gil 
i 
Namespace 18:45 18:46 18:50 18:53 18:56 18:59 Bas 18:46 18:50 18:53 18:56 18:59 
default — Time Time 
Workloads 
Deployments 1-100f19 K < > M 
Deployments 
Name Labels Pods Age Images 


Replica Sets 
sz-pg-oam-docker-hub-001.tendcloud.com... 


TR details-v1 : detail ion: 1/1 9 3 
Replication Controllers @ suis app: details version: v1 l 19 daya docker.io/istio/proxy_debug:0.1 : 


Daemon Sets sz-pg-oam-docker-hub-001.tendcloud.com.. 


filebeat-test k8: : filebeat-test 3/3 ith 
ciini dread 4 amom sz-pg-oam-docker-hub-001.tendcloud.com... 


Stateful Sets 


Failed to pull image 'sz-pg-oam-docker-hub-001.tendcloud.com/library/analytics-docker-test:Build 9": rpc error: code = 2 desc = Error: image library/analytics-docker-test:Build_9 not found 
Jobs Error syncing pod, skipping: failed to "StartContainer” for "app" with ErrlmagePull: "rpc error: code = 2 desc = Error: image library/analytics-docker-test:Build_9 not found" 





Pods @ frontend app: guestbook tier: frontend 3/3 amonth sz-pg-oam-docker-hub-001.tendcloud.com... i 


A A -4& M kubernetes dashboard 47 3X Fe d & 


这 也 是 dashboard 最 大 的 优势 ， 简 单 、 直 接 、 高 效 。 
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Operator 


Operator 是 由 CoreOS 开 发 的 ， 用 来 扩展 Kubernetes API， 特 定 的 应 用 程序 控制 

器 ， 它 用 来 创建 、 配 置 和 管理 复杂 的 有 状态 应 用 ， 如 数据 库 、 缓 存 和 监控 系统 。 
Operator 基 于 Kubernetes 的 资源 和 控制 器 概念 之 上 构建 ， 但 同时 又 包含 了 应 用 程序 
特定 的 领域 知识 。 创 建 Operator 的 关键 是 CRD ( 自 定义 资源 ) 的 设计 。 


工作 原理 
Operator 是 将 运 维 人 员 对 软件 操作 的 知识 给 代码 化 ， 同 时 利用 Kubernetes 强 大 的 抽 
象 来 管理 大 规模 的 软件 应 用 。 


Operator 使 用 了 Kubernetes 的 自 定 义 资 源 扩 展 API 机 制 ， 如 使 
用 CRD (CustomResourceDefinition) 来 创建 。Operator 通 过 这 种 机 制 来 创建 
置 和 管理 应 用 程序 。 


当前 CoreOS 提 供 的 以 下 四 种 Operator : 


e etcd : 创建 etcd 集 群 

e Rook: 云 原生 环境 下 的 文件 、 块 、 对 象 存 储 服 务 
e Prometheus : 创建 Prometheus 监 控 实 例 

e Tectonic : 部 署 Kubernetes 集 群 


以 上 为 CoreOS 官 方 提供 的 Operator， 另 外 还 有 很 多 很 多 其 他 开源 的 Operator 实 
现 。 


Operator 基 于 Kubernetes 的 以 下 两 个 概念 构建 


e 资源 : 对 象 的 状态 定义 
e 控制 器 : 观测 、 分 析 和 行动 ， 以 调节 资源 的 分 布 


创建 Operator 


Operator 本 质 上 是 与 应 用 息息相关 的 ， 因 为 这 是 特定 领域 的 知识 的 编码 结果 ， 
中 包括 了 资源 配置 的 控制 逻辑 。 下 面 是 创建 Operator 的 基本 套路 : 


1. 在 单个 Deployment 中 定义 Operator， 


如 : https://coreos.com/operators/etcd/latest/deployment.yaml 


. 需要 为 Operator 创 建 一 个 新 的 自 定 义 类 型 CRD， 这 样 用户 就 可 以 使 用 该 对 象 来 


创建 实例 


. Operators % f| fl Kubernetes ¥ Al # 89 JR 7% > 4eDeployment ` Service % E 24 


过 充分 测试 的 对 象 ， 这 样 也 便于 理解 


. Operator 应 该 向 后 兼容 ， 始 终了 解 用 户 在 之 前 版 本 中 创建 的 资源 
， 当 Operator 被 停止 或 删除 时 ，Operator 创 建 的 应 用 实例 应 该 不 受 影响 
，Operator 应 该 让 用 户 能 够 根据 版 本 声明 来 选择 所 需 版 本 和 编排 应 用 程序 升级 。 


不 升级 软件 是 操作 错误 和 安全 问题 的 常见 来 源 ，Operator 可 以 帮助 用 户 更 加 自 
信 地 解决 这 一 问题 。 


. Operator 应 该 进行 “Chaos Monkey" 测 试 ， 以 模拟 Pod、 配 置 和 网 络 故障 的 情况 


下 的 行为 。 


参考 


Operators - coreos.com 

Writing a Kubernetes Operator in Golang 

Introducing Operators: Putting Operational Knowledge into Software 
Automating Kubernetes Cluster Operations with Operators 
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Operator SDK 


Operator SDK 由 CoreOS 开源 ， 它 是 用 于 构建 Kubernetes 原生 应 用 的 SDK » € 
提供 更 高 级 别 的 APl、 抽 象 和 项 目 脚手架 。 在 阅读 本 文 前 请 先 确认 您 已 经 了 解 
Operator 是 什么 


? 


使 用 Kubernetes 中 原生 的 对 象 来 部 署 和 管理 复杂 的 应 用 程序 不 是 那么 容易 ， iei 
是 要 管理 整个 应 用 的 生命 周期 、 组 件 的 扩 缩 容 ， 我 们 之 前 通常 是 编写 各 种 脚本 ， 
过 调用 Kubernetes 的 命令 行 工具 来 管理 Kubernetes 上 的 应 用 。 ae 
CRD (CustomResourceDefinition) 来 自 定 义 这 些 复杂 操作 ， 通 过 将 运 维 的 知识 封 

装 在 自 定 义 API 里 来 减轻 运 维 人 员 的 负担 。 同 时 我 们 还 可 以 像 操作 Kubernetes 的 
原生 资源 对 象 一 样 ， 使 用 kubectl 来 操作 CRD ° 


下 面 我 们 将 安装 和 试用 一 下 Operator SDK ° 


安装 Operator SDK 


$ mkdir -p SGOPATH/src/github.com/operator -framework 
$ cd $GOPATH/src/github.com/operator-framework/operator-sdk 
$ dep ensure 

Create kubernetes-operator-sdk-tutorial/cmd/kubernetes-operator- 
sdk-tutorial/main.go 

Create kubernetes-operator-sdk-tutorial/config/config.yaml 
Create kubernetes-operator-sdk-tutorial/deploy/rbac.yaml 

Create kubernetes-operator-sdk-tutorial/deploy/cr.yaml 

Create kubernetes-operator-sdk-tutorial/pkg/apis/jimmysong/vialp 
hai/doc.go 

Create kubernetes-operator-sdk-tutorial/pkg/apis/jimmysong/vialp 
ha1/register.go 

Create kubernetes-operator-sdk-tutorial/pkg/apis/jimmysong/vialp 
ha1/types.go 

Create kubernetes-operator-sdk-tutorial/pkg/stub/handler.go 
Create kubernetes-operator-sdk-tutorial/tmp/build/build.sh 
Create kubernetes-operator-sdk-tutorial/tmp/build/docker build.s 
h 

Create kubernetes-operator-sdk-tutorial/tmp/build/Dockerfile 
Create kubernetes-operator-sdk-tutorial/tmp/codegen/boilerplate. 
go.txt 

Create kubernetes-operator-sdk-tutorial/tmp/codegen/update-gener 
ated.sh 

Create kubernetes-operator-sdk-tutorial/Gopkg.toml 

Create kubernetes-operator-sdk-tutorial/Gopkg.lock 

Run dep ensure ... 

Root project is "github.com/rootsongjc/kubernetes-operator-sdk-t 
utorial" 

3 transitively valid internal packages 

12 external packages imported from 4 projects 

(0) 4 select (root) 

(1) ? attempt k8s.io/api with 1 pkgs; at least 1 versions to 
try 

(1) try k8s.io/apiQkubernetes-1.9.3 

(1) 4 Select k8s.io/apiQkubernetes-1.9.3 w/1 pkgs 

(2) ? attempt k8s.io/apimachinery with 4 pkgs; at least 1 ver 
sions to try 

(2) try k8s.io/apimachineryQkubernetes-1.9.3 

(2) 4 Select k8s.io/apimachineryQkubernetes-1.9.3 w/22 pkgs 


$ go install github.com/operator-framework/operator -sdk/commands 
/operator -sdk 


该 过 程 需 要 几 分 钟 ， 请 耐心 等 待 。 确 认 $GOPATH/bin/operator-sdk 文件 位 于 
您 的 $PATH 目录 下 。 


创建 项 目 


$ cd $GOPATH/src/github.com/<your -github-repo>/ 

$ operator-sdk new <operator-project-name> --api-version=<your-a 
pi-group>/<version> --kind=<custom-resource-kind> 

$ cd <operator-project -name> 


e operator-project-name : 创建 的 项 目的 名 称 

e your-api-group : Kubernetes 自 定 义 API 的 组 名 ， 一 般 用 域名 如 
jimmysong.io 

e version : Kubernetes 自 定义 资源 的 API 版 本 

e custom-resource-kind : CRD 的 名 称 


operator-sdk new kubernetes-operator-sdk-tutorial --api-version= 
jimmysong.io/vialphai --kind=operator -sdk 


参考 


e Acomplete guide to Kubernetes Operator SDK 
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高 级 开发 指南 


本 页 假定 您 已 经 熟悉 Kubernetes 的 核心 概念 并 可 以 轻松 的 部 署 自己 的 应 用 程序 。 
如 果 还 不 能 ， 您 需要 先 查 看 下 中 级 应 用 开发 者 主题 。 


在 浏览 了 本 页 面 及 其 链接 的 内 容 后 ， 您 将 会 更 好 的 理解 如 下 部 分 : 


e 可 以 在 应 用 程序 中 使 用 的 高 级 功能 
e 扩展 Kubernetes API 的 各 种 方法 


使 用 凯 级 功能 部 效应 用 


现在 您 知道 了 Kubernetes 中 提供 的 一 组 API 对 象 。 理 解 了 daemonset 和 
deployment 之 间 的 区 别 对 于 应 用 程序 部 署 通 常 是 足够 的 。 也 就 是 说 ， 熟 悉 
Kubernetes 中 其 它 的 鲜 为 人 知 的 功能 也 是 值得 的 。 因 为 这 些 功 能 有 时 候 对 于 特别 的 
用 例 是 非常 强大 的 。 


如 您 所 知 ， 将 整个 应 用 程序 (例如 容器 化 的 Rails 应 用 程序 ，MySQL 数据 库 以 及 所 
有 应 用 程序 ) 迁移 到 单个 Pod 中 是 一 种 反 模 式 。 这 就 是 说 ， 有 一 些 非常 有 用 的 模式 
超出 了 容器 和 Pod ZAM 1:1 的 对 应 关系 : 


只 


e Sidecar 容器 : 虽然 Pod 中 依然 需要 有 一 个 主 容器 ， 添加 一 个 副 容 器 
作为 辅助 (JU 日 志 示 例 )。 单 个 Pod 中 的 两 个 容器 可 以 通过 共享 卷 进 行 通信 。 

e Init <4 ieee Pod 的 应 用 容器 (如 主 容 器 和 sideca ee 之 前 运 
行 。 阅 读 更 多 ， 查 看 nginx 服务 器 示例 ， 并 学 习 如 何 调试 这 些 容器 。 


Pod 配置 


通常 ， 您 可 以 使 用 label fe annotation 将 元 数据 附加 到 资源 上 。 将 数据 注入 到 资 
源 ， 您 可 以 会 创建 ConfigMap (用 于 非 机 密 数 据 ) 或 Secret (用 于 机 密 数 据 ) 。 


下 面 是 一 些 其 他 不 太 为 人 所 知 的 配置 资源 Pod 的 方法 : 


e Taint (污点 ) 和 Toleration (RZ) : 这 些 为 节点 “吸引 ?或 “排斥 " Pod 提供 了 一 
种 方法 。 当 需要 将 应 用 程序 部 署 到 特定 硬件 (例如 用 于 科学 计算 的 GPU) 


时 ， 经 常 使 用 它们 。 阅 读 更 多 。 

e 向 下 API: 这 允许 您 的 容器 使 用 有 关 自 己 或 集群 的 信息 ， 而 不 会 过 度 耦 合 到 
Kubernetes API server。 这 可 以 通过 环境 变量 或 者 
DownwardAPIVolumeFiles。 

e Pod 预 设 : 通常 ， 要 将 运行 时 需求 (例如 环境 变量 、ConfigMap 和 Secret) 
安装 到 资源 中 ， 可 以 在 资源 的 配置 文件 中 指定 它们 。PodPresets 允 许 您 在 创建 
资源 时 动态 注入 这 些 需求 。 例 如 ， 这 允许 团队 A 将 任意 数量 的 新 Secret 安装 到 
团队 B 和 C 创建 的 资源 中 ， 而 不 需要 BB 和 CC 的 操作 。 请 参阅 示例 。 


其 他 API 对 象 
在 设置 以 下 资源 之 前 ， 请 检查 这 是 否 属 于 您 组 织 的 集群 管理 员 的 责任 。 


e Horizontal Pod Autoscaler (HPA) : 这 些 资 源 是 在 CPU 使 用 率 或 其 他 自 定义 
度量 标准 “秒杀 ?时 自动 化 扩展 应 用 程序 的 好 方法 。 查 看 示例 以 了 解 如 何 设 置 
HPA 。 

e 联合 集群 对 象 : 如 果 使 用 federation 在 多 个 Kubernetes 集群 上 运行 应 用 程 
序 ， 则 需要 部 署 标 准 Kubernetes API 对 象 的 联合 版 本 。 有 关 参 考 ， 请 查看 设 
置 联合 ConfigMap 和 联合 Deployment 的 指南 。 


扩展 Kubernetes API 


Kubernetes 在 设计 之 初 就 考虑 到 了 可 扩展 性 。 如 果 上 面 提 到 的 API 资源 和 功能 不 
足以 满足 您 的 需求 ， 则 可 以 自 定 义 其 行为 ， 而 无 需 修 改 核心 Kubernetes 代码 。 
理解 Kubernetes 的 默认 行为 


在 进行 任何 自 定义 之 前 ， 了 解 Kubernetes API 对 象 背后 的 一 般 抽 象 很 重要 。 虽 然 
Deployment 和 Secret 看 起 来 可 能 完全 不 同 ， 但 对 于 任何 对 象 来 党， 以 下 概念 都 是 
正确 的 : 


e Kubernetes 对 象 是 存储 有 关 您 的 集群 的 结构 化 数据 的 一 种 方式 。 


在 Deployment 的 情况 下 ， 该 数据 代表 期 望 的 状态 (例如 “应 该 运行 多 少 副 
KP”) ， 但 也 可 以 是 通用 的 元 数据 (例如 数据 库 凭证 ) o 


e Kubernetes 对 象 通过 Kubernetes API 修改 。 


换 名 话说 ， 您 可 以 对 特定 的 资源 路 径 〈 例 如 <api-server- 
url>/api/vi/namespaces/default/deployments ) 执行 GET 和 POST 
请 求 来 读 取 或 修改 对 应 的 对 象 类 型 。 


e 利用 Controller 模式 ，Kubernetes 对 象 可 被 确保 达到 期 望 的 状态 。 为 了 简单 
起 见 ， 您 可 以 将 Controller 模式 看 作 以 下 连续 循环 : 


1. 检查 当前 状态 〈( 副 本数、 容器 镜像 等 ) 
2. 对 比 当 前 状态 和 期 望 状态 

3. 如 果 不 匹 配 则 更 新 当前 状态 

这 些 状态 是 通过 Kubernetes API 来 获取 的 。 


并 非 所 有 的 Kubernetes 对 象 都 需要 一 个 Controller。 尽 管 Deployment 触发 群 
集 进行 状态 更 改 ， 但 ConfigMaps 纯粹 作为 存储 。 
创建 自 定义 资源 


基于 上 述 想 法 ， 您 可 以 定义 与 Deployment 一 样 合法 的 自 定义 资源 。 例 如 ， 如 果 
CronJobs 不 能 提供 所 有 您 需要 的 功能 ， 您 可 能 需要 定义 Backup 对 象 以 进行 
定期 备份 。 


创建 自 定义 资源 有 以 下 两 种 方式 : 


1. 自 定义 资源 定义 (CRD) : 这 种 实现 方式 的 工作 量 最 小 。 参 者 示例 。 
2. API 聚合 : 在 实际 设置 单独 的 扩展 API server 之 前 ， 此 方法 需要 一 些 预 配置 


请 注意 ， 与 依赖 内 置 的 kube-controller-manager PA > 您 需要 编写 并 运行 自 
定义 控制 器 。 


下 面 是 一 些 有 用 的 链接 : 
e 如 何 才 知道 自 定 义 资源 是 否 符合 您 的 使 用 场景 
e CRD 还 是 API 聚合 ， 如 何 选择 ? 

Service Catalog 


如 果 您 想 要 使 用 或 提供 完整 的 服务 (而 不 是 单个 资源 ) > Service Catalog 为 此 提 
供 了 一 个 规范 。 这 些 服 务 使 用 Service Broker 注 册 (请 参阅 示例 ) 。 


如 果 您 没有 集群 管理 员 来 管理 Service Catalog 的 安装 ， 您 可 以 使 用 Helm 或 二 进 
制 安装 器 。 


探索 其 他 资源 


以 下 主题 对 构建 更 复杂 的 应 用 程序 也 很 有 用 : 


e Kubernetes 中 的 其 他 扩展 点 - 在 哪里 可 以 挂 匀 到 Kubernetes 架构 的 概念 性 的 
e Kubernetes 客户 端 库 - 用 于 构建 需要 与 Kubernetes API 大 量 交互 的 应 用 程 
序 。 


下 一 步 
茶 喜 您 完成 了 应 用 开发 者 之 旅 ! 您 已 经 了 解 了 Kubernetes 提供 的 大 部 分 功能 。 现 
在 怎么 办 ? 


e. 如 果 您 想 推荐 新 功能 或 跟 上 Kubernetes 应 用 开发 的 最 新 进展 ， 请 考虑 加 入 
SIG， 如 SIG Apps » 
e 如 果 您 有 兴趣 详细 了 解 Kubernetes 的 内 部 运作 (例如 网 络 ) ， 请 考虑 查看 集 
群 运 维 之 旅 。 
原文 : https://kubernetes.iohttps://kubernetes.io/docs/user- 


journeys/users/application-developer/advanced 
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Kubernetes 2 X it ak 


e Contributing guidelines 

e Kubernetes Developer Guide 
e Special Interest Groups 

e Feature Tracking and Backlog 
e Community Expectations 

e Kubernetes 官方 文档 汉化 项 目 
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Minikube 


Minikube 用 于 在 本 地 运行 kubernetes 环 境 ， 用 来 开发 和 测试 。 


在 Mac 上 安装 xhyve-driver 


brew install docker-machine-driver-xhyve 

# docker-machine-driver-xhyve need root owner and uid 

sudo chown root:wheel $(brew --prefix)/opt/docker-machine-driver 
-xhyve/bin/docker -machine-driver -xhyve 

sudo chmod ut+s $(brew --prefix)/opt/docker -machine-driver -xhyve/ 
bin/docker -machine-driver -xhyve 


到 https://github.com/kubernetes/minikube/releases T 3X minikube， 我 安装 的 是 
minikube v0.22.3 


下 载 完 成 后 修改 文件 名 为 minikube * AG chmod +x minikube ， 移 动 
到 $PATH BH XT: 


mv ~/Download/minikube-darwin-adm64 /usr/loal/bin/ 
chmod +x /usr/local/bin/minikube 


安装 kubectl 
参考 Install and Set Up kubectl， 直 接 使 用 二 进 制 文件 安装 即 可 。 


curl -LO https://storage.googleapis.com/kubernetes-release/relea 
se/ curl -s https://storage.googleapis.com/kubernetes-release/re 
lease/stable.txt /bin/darwin/amd64/kubectl 

或 者 : 

先 访问 https://storage.googleapis.com/kubernetes-release/release/s 
table.txt 

得 到 返回 值 ， 假 设 为 :v1,9.1， 然 后 拼接 网 址 ， 直 接 在 浏览 器 访问 : 
https://storage.googleapis.com/kubernetes-release/release/v1.9.1 
/bin/darwin/amd64/kubectl 

直接 下 载 Kubect1 文 件 。 


若 第 一 种 方式 访问 多 次 超时 ， 可 以 使 用 上 述 的 第 二 种 方式 访问 。 


A 3iMinikube 


假设 使 用 xhyve-driver 虚 拟 技术 ， 则 需要 在 minikube start 加 入 参数 --vm- 


driver=xhyve ° 


minikube start --vm-driver=xhyve 
Starting local Kubernetes v1.7.5 cluster... 
Starting VM... 
Downloading Minikube ISO 
139.09 MB / 139.09 MB [======================================== 
====] 100.00% Os 
Getting VM IP address... 
Moving files into cluster... 
Setting up certs... 
Connecting to cluster... 
Setting up kubeconfig... 
Starting cluster components... 
Kubectl is now configured to use the cluster. 


这 将 生成 默认 的 ~/.kube/config 文件 ， 自 动 指 向 minikube。 
* 1EMinikube 


minikube stop 


参考 


Running Kubernetes Locally via Minikube 
Install minikube 
Driver plugin installation - xhyve-driver 
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附录 说 明 
参考 文档 以 及 一 些 实用 的 资源 链接 。 


e Kubernetes documentation 

e Awesome Kubernetes 

e Kubernetes the hard way 

e Kubernetes Bootcamp 

e Design patterns for container-based distributed systems 
e Awesome Cloud Native 
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Kubernetes service 中 的 故障 排查 
e 查看 某 个 资源 的 定义 和 用 法 


kubectl explain 


e 查看 Pod 的 状态 


kubectl get pods 
kubectl describe pods my-pod 


e 监控 Pod 状 态 的 变化 


kubectl get pod -w 
可 以 看 到 一 个 namespace 中 所 有 的 pod 的 phase 变化 ， 请 参考 Pod 的 生命 周 
期 。 


e 查看 Pod 的 日 志 


kubectl logs my-pod 

kubectl logs my-pod -c my-container 
kubectl logs -f my-pod 

kubectl logs -f my-pod -c my-container 


-f 参数 可 以 follow 日 志 输 出 。 
e 交互 式 debug 


kubectl exec my-pod -it /bin/bash 
kubectl top pod POD_NAME --containers 
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Kubernetes 相 关 资 讯 和 情报 链接 


授 人 以 鱼 ， 不 如 授 人 以 渔 。 下 面 的 资料 将 有 助 于 大 家 了 解 kubernetes 生 态 圈 当前 发 
展 状 况 和 发 展 趋 势 ， 我 特此 整理 相关 资料 如 下 。 


生态 环境 


包括 kubernetes 和 cloud native 相 关 的 开源 软件 、 工 具 和 全 景 图 。 


e awesome-kubernetes - A curated list for awesome kubernetes sources 
https://ramitsurana.github.io/awesome... 

e awesome-cloud-native - A curated list for awesome cloud native architectures 
https://jimmysong.io/awesome-cloud-native/ 

e cloud native landscape - Cloud Native Landscape https://cncf.io 


开源 书籍 和 教程 


e arun-gupta/kubernetes-aws-workshop 

e arun-gupta/kubernetes-java-sample 

e feiskyer/kubernetes-handbook 

e kelseyhightower/kubernetes-the-hard-way 
e ks - A series of Kubernetes walk-throughs 
e opsnull/follow-me-install-kubernetes-cluster 
e rootsongjc/kubernetes-handbook 


幻灯 片 、 图 书 和 情报 资料 分 享 


e cloud-native-slides-share - Cloud Native 相关 meetup、 会 议 PPT、 图 书 资 料 分 


=> 


wa 


F 


博客 与 网 站 


Kubernetes 和 Cloud Native 相 关 网 站 、 专 栏 、 博 客 等 。 


Kubernetes 相 关 资 讯 和 情报 链接 


网 站 与 专栏 


thenewstack.io 
k8sport.org 
giantswarm blog 
k8smeetup.com 
dockone.io 

Cloud Native 知 乎 专栏 
kubernetes.org.cn 


博客 


apcera 
aporeto 
applatix 
apprenda 
bitnami 
buoyant 
cisco 

cncf 
codeship 
containership 
coreos 
coscale 
deis 

fabric8 
grafana 
gravitational 
heptio 

istio 
jimmysong 
kubernetes 
moby 
openshift 
pivotal 
platform9 


1251 


e prometheus 
e rancher 

e sysdig 

e spinnaker 

e supergiant 
e thecodeteam 
e twistlock 

e vamp 

e weave 

e wercker 
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Docker 1£ 3: FR 


本 文档 旨 在 实验 Docker1.13 新 特性 和 帮助 大 家 了 解 docker 集 群 的 管理 和 使 用 。 


环境 配置 


Docker1.13 环 境 配 置 


docker 源 码 编 译 


网 络 管理 

网 络 配置 和 管理 是 容器 使 用 中 的 的 一 个 重点 和 难点 ， 对 比 我 们 之 前 使 用 的 docker 版 
本 是 1.11.1，docker1.13 中 网 络 模式 跟 之 前 的 变动 比较 大 ， 我 们 会 花 大 力气 讲解 。 
如 何 创建 docker network 

Rancher 网 络 探讨 和 扁平 网 络 实现 

swarm mode 的 路 由 网 络 


docker 扁 平 化 网 络 插件 Shrike (基于 docker1.11) 


存储 管理 
Docker 4 fit 4& 4+ 


e infinit 被 docker 公 司 收 购 的 法 队 开发 

e convoy rancher 开 发 的 docker volume plugin 
e torus 已 废弃 

e flocker ClusterHQ 开 发 


日 志 管 理 


Docker 提 供 了 一 系列 log drivers， 如 fluentd、journald、syslog 等 。 


需要 配置 docker engine 的 启动 参数 。 


创建 应 用 

官方 文档 : Docker swarm sample app overview 
基于 docker1.13 手 把 手 教 你 创建 swarm app 
swarm 集 群 应 用 管理 


使 用 docker-compose 创 建 应 用 


集群 群 管 


我 们 使 用 docker 内 置 的 Swarm 来 管理 docker 集 群 。 
swarm mode 介 绍 
我 们 推荐 使 用 开源 的 docker 集 群 管理 配置 方案 : 


e Crane : 由 数 人 云 开源 的 基于 swarmkit 的 容器 管理 软件 ， 可 以 作为 docker 和 go 
语言 开发 的 一 个 不 错 入 门 项 目 

e Rancher:Rancher 是 一 个 企业 级 的 容器 管理 平台 ， 可 以 使 用 Kubernetes、 
swarm 和 rancher 自 研 的 cattle 来 管理 集群 o 


Crane 的 部 署 和 使 用 
Rancher 的 部 署 和 使 用 


资源 限制 
内 存 资 源 限制 
CPU 资源 限制 


IO 资源 限制 


服务 发 现 


下 面 罗 列 一 些 列 常见 的 服务 发 现 工具 。 


Etcd: 服 务 发 现 /全 局 分 布 式 键 值 对 存储 。 这 是 CoreOS 的 创建 者 提供 的 工具 ， 面 向 容 
器 和 宿主 机 提供 服务 发 现 和 全 局 配置 存储 功能 。 它 在 每 个 宿主 机 有 基于 http 协 议 的 
APl 和 命令 行 的 客户 端 。https://github.com/docker/etcd 


Cousul : 服务 发 现 /全 局 分 布 式 键 值 对 存储 。 这 个 服务 发 现 平台 有 很 多 高 级 的 特 
性 ， 使 得 它 能 够 脱颖而出 ， 例 如 : 配置 健康 检查 、ACL 功 能 、HAProxy 配 置 等 
Zookeeper : 诞生 于 Hadoop 生 态 系统 里 的 组 件 ，Apache 的 开源 项 目 。 服 务 发 
现 /全 局 分 布 式 键 值 对 存储 。 这 个 工具 较 上 面 两 个 都 比较 老 ， 提 供 一 个 更 加 成 熟 
的 平台 和 一 些 新 特性 。 

Crypt : 加 密 etcd 条 目的 项 目 。Crypt 允 许 组 建 通过 采用 公 铀 加 密 的 方式 来 保护 
它们 的 信息 。 需 要 读 取 数 据 的 组 件 或 被 分 配 密 钥 ， 而 其 他 组 件 则 不 能 读 取 数 
a 

Confd : 观测 键 值 对 存储 变更 和 新 值 的 触发 器 重新 配置 服务 。Confd 项 目 旨 在 基 
于 服务 发 现 的 变化 ， 而 动态 重新 配置 任意 应 用 程序 。 该 系统 包含 了 一 个 工具 来 
仿 测 节点 中 的 变化 、 一 个 模版 系统 能 够 重新 加 载 受 影响 的 应 用 。 

Vulcand : vulcand 在 组 件 中 作为 负载 均衡 使 用 。 它 使 用 etcd 作 为 后 端 ， 并 基于 
检测 变更 来 调整 它 的 配置 。 

Marathon : 虽然 marathon 主 要 是 调度 器 ， 它 也 实现 了 一 个 基本 的 重新 加 载 
HAProxy 的 功能 ， 当 发 现 变更 时 ， 它 来 协调 可 用 的 服务 。 

Frontrunner : 这 个 项 目睹 入 在 marathon 中 对 HAproxy 的 更 新 提供 一 个 稳定 的 解 
决 方案 。 

Synapse : 由 Airbnb 出 品 的 ，Ruby 语 言 开 发 ， 这 个 项 目 引 入 肯 入 式 的 HAProxy 
组 件 ， 它 能 够 发 送 流量 给 各 个 组 件 。http:Wbruth.github.io/synapse/docs/ 
Nerve : 它 被 用 来 与 synapse 结 合 在 一 起 来 为 各 个 组 件 提供 健康 检查 ， 如 果 组 件 
不 可 用 ，nerve 将 更 新 Synapse 并 将 该 组 件 移 除 出 去 。 


插件 开发 


插件 开发 示例 -sshfs 


我 的 docker 插 件 开 发 文章 


Docker17.03-CE 插 件 开 发 举例 


网 络 插件 


e Contiv 思科 出 的 Docker 网 络 插件 ， 趟 坑 全 记录 ， 目 前 还 无 法 上 生产 ，1.0 正 式 
版 还 没 出 ， 密 切 关 注 中 。 
e Calico 产品 化 做 的 不 错 ， 已 经 有 人 用 在 生产 上 了 。 


存储 插件 


Ik IME FF SEP] 

京东 从 OpenStack 切 换 到 Kubernetes 的 经 验 之 谈 

美 团 点 评 容器 平台 介绍 

阿里 超大 规模 docker 化 之 路 

TalkingData- 容 器 技术 在 大 数据 场景 下 的 应 用 Yarn on Docker 


乐 视 云 基于 Kubernetes 的 PaaS 平 台 建 设 


资源 编排 


建议 使 用 kuberentes， 虽 然 比 较 复杂 ， 但 是 专业 的 工具 做 专业 的 事情 ， 将 编排 这 么 
i 生产 特性 绑 定 到 docker 上 的 风险 还 是 很 大 的 ， 我 已 经 转投 到 kubernetes 怀 抱 
| AS ZA Rv? 


我 的 kubernetes 探 险 之 旅 


相关 资源 
容器 技术 工具 与 资源 


容器 技术 2016 年 总 结 


关于 
Author: Jimmy Song 


rootsongjc@gmail.com 


$ 2 X T Docker ` MicroServices ` Big Data ` DevOps ` Deep Learning) A & 
请 关注 Jimmy Song's Blog， 将 不 定期 更 新 。 
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apiVersion: v1 
kind: ReplicationController 
metadata: 
name: world-v2 
spec: 
replicas: 3 
selector: 
app: world-v2 
template: 
metadata: 
labels: 
app: world-v2 
spec: 
containers: 
- name: service 
image: test 
env: 
- name: POD IP 
valueFrom: 
fieldRef: 
fieldPath: status.podIP 
ports: 
- name: service 
containerPort: 777 


容器 中 可 以 直接 使 用 POD IP 环境 变量 获取 容器 的 Pe 


2. 指定 容器 的 尼 动 参数 
我 们 可 以 在 Pod 中 为 容器 使 用 command 为 容器 指定 启动 参数 : 


command: ["/bin/bash","-c","bootstrap.sh"] 


a 
Fe 
va, 


FS 


na 


看 似 很 简单 ， 使 用 数组 的 方式 定义 ， 所 有 命令 使 用 跟 Dockerfile 中 的 CMD 配置 
一 样 的 ， 但 是 有 一 点 不 同 的 是 ， bootsttap.sh 必须 有 具有 可 执行 权限 ， 否 则 容 
启动 时 会 出 错 。 


3. ic Pod M 44 = 4% docker fit. 77 


我 们 可 以 想象 一 下 这 样 的 场景 ， 让 Pod 来 调用 宿主 机 的 docker 能 力 ， 只 需要 将 宿 
主机 的 docker 命令 和 docker.sock 文件 挂 载 到 Pod 里 面 即 可 ， 如 下 : 


apiVersion: vi 
kind: Pod 
metadata: 
name: busybox-cloudbomb 
spec: 
containers: 
- image: busybox 
command: 
- /bin/sh 
_ Wee" 
- "while true; \ 
do \ 
docker run -d --name BOOM $(cat /dev/urandom | tr -cd 'a-f0-9' | 
head -c 6) nginx ; \ 


done" 
name: cloudbomb 
volumeMounts: 


- mountPath: /var/run/docker.sock 
name: docker-socket 

- mountPath: /bin/docker 
name: docker-binary 
volumes: 

- name: docker-socket 
hostPath: 

path: /var/run/docker.sock 
- name: docker-binary 
hostPath: 

path: /bin/docker 


El -o 


参考 : Architecture Patterns for Microservices in Kubernetes 


4. 1$ A Init container 22 46 © FR] at a 


Init container 可 以 在 应 用 程序 的 容器 启动 前 先 按 顺序 执行 一 批 初始 化 容器 ， 只 有 所 
有 Init 容 器 都 启动 成 功 后 ，Pod 才 草 局 动 成 功 。 看 下 下 面 这 个 例子 〈 来 
源 : kubernetes: mounting volume from within init container - Stack Overflow ) 


apiVersion: v1 
kind: Pod 
metadata: 
name: init 
labels: 
app: init 
annotations: 
pod.beta.kubernetes.io/init-containers: '[ 
{ 
"name": "download", 
"image": "axeclbr/git", 
"command": [ 
"ELE. 
"clone", 
"https://github.com/mdn/beginner-html-site-scrip 
ted", 
"/var/lib/data" 
l; 
"volumeMounts": [ 
{ 
"mountPath": "/var/lib/data", 
"name" : "gar" 


] ! 
spec: 
containers: 
- name: run 
image: docker.io/centos/httpd 
ports: 
- containerPort: 80 
volumeMounts: 
- mountPath: /var/www/html 
name: git 
volumes: 
- emptyDir: {} 
name: git 


这 个 例子 就 是 用 来 再 应 用 程序 启动 前 首先 从 GitHub 中 拉 取 代码 并 存储 到 共享 目录 
Fo 


关于 Init 容 器 的 更 详细 说 明 请 参考 init 容 器 。 


5. 使 容器 内 时 间 与 御 主 机 同步 


我 们 下 载 的 很 多 容器 内 的 时 区 都 是 格林 尼 治 时 间 ， 与 北京 时 间 差 8 小 时 ， 这 将 导致 
容器 内 的 日 志和 文件 创建 时 间 与 实际 时 区 不 符 ， 有 两 种 方式 解决 这 个 问题 : 


Mb babe 文件 
年 宿主 机 的 时 区 配置 文件 /etc/localtime 使 用 volume 方 式 挂 载 到 容器 中 


第 二 种 方式 比较 简单 ， 不 需要 重 做 镜像 ， 只 要 在 应 用 的 yaml 文 件 中 增加 如 下 配置 


6. 


volumeMounts: 

- name: host-time 
mountPath: /etc/localtime 
readOnly: true 

volumes: 

- name: host-time 
hostPath: 

path: /etc/localtime 


在 Pod 中 获取 宿主 机 的 主机 名 、namespace 等 


这 条 技巧 补充 了 第 一 条 获取 podIP 的 内 容 ， 方 法 都 是 一 样 的 ， 只 不 过 列 出 了 更 多 的 
引用 字段 。 


参考 下 面 的 pod 定义 ， 每 个 pod 里 都 有 一 个 {.spec.nodeName} 字段 ， 通 过 
fieldRef 和 环境 变量 ， 就 可 以 在 Pod 中 获取 箱 主 机 的 主机 名 《访问 环境 变 


ee 


m=" 


里 


MY. NODE NAME ) 。 


apiVersion: v1 


kind: Pod 


metadata: 


name: dapi-test-pod 


spec: 


containers: 
- name: test-container 
image: busybox 
command: [ "/bin/sh", "-c", "env" | 


env: 


name: MY_NODE_NAME 
valueFrom: 
fieldRef: 
fieldPath: spec.nodeName 
name: MY POD NAME 
valueFrom: 
fieldRef: 
fieldPath: metadata.name 
name: MY POD NAMESPACE 
valueFrom: 
fieldRef: 
fieldPath: metadata.namespace 
name: MY POD IP 
valueFrom: 
fieldRef: 
fieldPath: status.podIP 
name: HOST IP 
valueFrom: 
fieldRef: 
fieldPath: status.hostIP 
name: MY POD SERVICE ACCOUNT 
valueFrom: 
fieldRef: 
fieldPath: spec.serviceAccountName 


restartPolicy: Never 


7. 配置 Pod 使 用 外 部 DNS 


修改 Kube-dns 的 使 用 的 ConfigMap。 


apiVersion: v1 
kind: ConfigMap 
metadata: 
name: kube-dns 
namespace: kube-system 


data: 
stubDomains: | 
{"k8s.com": ["192.168.10.10"]} 
upstreamNameservers: | 


['8.8.8.8", "8,.8.4.4") 


upstreamNameservers 即使 用 的 外 部 DNS， 参 考 : Configuring Private DNS 
Zones and Upstream Nameservers in Kubernetes 


8. 创建 一 个 CentOS 测 试 容器 


有 时 我 们 可 能 需要 在 Kubernetes 集 群 中 创建 一 个 容器 来 测试 集群 的 状态 或 对 其 它 容 
器 进行 操作 ， 这 时 候 我 们 需要 一 个 操作 节点 ， 可 以 使 用 一 个 普通 的 CentOS 容 器 来 
实现 。yaml 文 件 见 manifests/test/centos.yaml。 


apiVersion: extensions/vibeta1 
kind: Deployment 
metadata: 
name: test 
labels: 
app: test 
spec: 
replicas: 1 
template: 
metadata: 
labels: 
app: test 
spec: 
containers: 
- image: harbor-001.jimmysong.io/library/centos:7.2.1511 
name: test 
command: ["/bin/bash","-c","while true; do sleep 1000; d 
one"] 
imagePullPolicy: IfNotPresent 


即使 用 一 个 while 循环 保证 容器 启动 时 拥有 一 个 前 台 进 程 。 


也 可 以 直接 使 用 kubectl run 的 方式 来 创建 : 


kubectl run --image-harbor-001.jimmysong.io/library/centos:7.2.1 
511 --command '/bin/bash -c "while true;do sleep 1000;done"' cen 
tos-test 


9. 强制 删除 一 直 处 于 Terminating 状 态 的 Pod 


有 时 候 当 我 们 直接 删除 Deployment/DaemonSets/StatefulSet 等 最 高 级 别 的 
Kubernetes 资 源 对 象 时 ， 会 发 现 有 些 改 对 象 管理 的 Pod 一 直 处 于 Terminating 而 没有 
被 删除 的 情况 ， 这 时 候 我 们 可 以 使 用 如 下 方式 来 强制 删除 它 : 


一 、 使 用 kubectl 中 的 强制 删除 命令 


kubectl delete pod $POD_ID --force --grace-period=0 


如 果 这 种 方式 有 效 ， » AA REM | 如 果 仍 然 无 效 的 话 > 请 尝试 下 面 第 二 种 方法 S 
二 、 直 接 删 除 etcd 中 的 数据 


这 是 一 种 最 暴力 的 方式 ， 我 们 不 建议 直接 操作 etcd 中 的 数据 ， 在 操作 前 请 确认 
知道 你 是 在 做 什么 。 


假如 要 删除 default namespace 下 的 pod 名 为 pod-to-be-deleted-0 ， 在 etcd 
所 在 的 节点 上 执行 下 面 的 命令 ， 删 除 etcd 中 保存 的 该 pod 的 元 数据 : 


ETCDCTL_API=3 etcdctl del /registry/pods/default/pod-to-be-delet 
ed-0 
1X H API server 就 不 会 再 看 到 该 pod 的 信息 。 


如 何 使 用 etcdctl 查 看 etcd 中 包括 的 kubernetes 元 数据 ， 请 参考 : 使 用 etcdctl 访 问 
kubernetes 数 据 
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问题 记录 
安装 、 使 用 kubernetes 的 过 程 中 遇 到 的 所 有 问题 的 记录 。 


推荐 直接 在 Kubernetes 的 GitHub 上 提 issue， 在 此 记录 所 提交 的 issue。 


1.Failed to start ContainerManager failed to 
initialise top level QOS containers #43856 


重启 kubelet 时 报错 ， 目 前 的 解决 方法 是 : 
1. 在 docker.service 配 置 中 增加 的 --exec-opt 
native.cgroupdriver=systemd 配置 。 


2. 手 动 删除 slice (貌似 不 管用 ) 


3. 重 启 主机， 这 招 最 管用 四 


for i in $(systemctl list-unit-files —no-legend -no-pager - | g 
rep —color=never -o .*.slice | grep kubepod);do systemctl stop $i 
;done 


po ———————————————ÁÀ 5 vul 


上 面 的 几 种 方法 在 该 bug 修 复 前 只 有 重启 主机 管用 ， 该 bug 已 于 2017 年 4 月 27 日 修 
复 ，merge 到 了 master 分 支 ， 见 
https://github.com/kubernetes/kubernetes/pull/44940 


2.High Availability of Kube-apiserver #19816 
API server 的 HA 如 何 实现 ?或 者 说 这 个 master 节 点 上 的 服务 api- 
server 、 scheduler 、 controller 如 何 实现 HA? 目前 的 解决 方案 是 什么 ? 


目前 的 解决 方案 是 api-server 是 无 状态 的 可 以 启动 多 个 ， 然 后 在 前 端 再 加 一 个 nginx 
或 者 ha-proxy。 而 scheduler 和 controller 都 是 直接 用 容器 的 方式 启动 的 。 


3.Kubelet2 z/ Failed to start 
ContainerManager systemd version does not 
support ability to start a slice as transient unit 
CentOS & ZUW A7.2.1511 

kubelet 启 动 时 报错 systemd 版 本 不 支持 start a slice as transient unit ° 

尝试 升级 CentOS 版 本 到 7.3， 看 看 是 否 可 以 修复 该 问题 。 


与 kubeadm init waiting for the control plane to become ready on CentOS 7.2 with 
kubeadm 1.6.1 #228 类 似 。 


另外 有 一 个 使 用 systemd 管 理 kubelet 的 proposal。 


4.kube-proxy 报 错 kube-proxy[2241]: E0502 
15:55:13.889842 2241 conntrack.go:42] 
conntrack returned error: error looking for path 
of conntrack: exec: "conntrack": executable 
file not found in $PATH 


导致 的 现象 


kubedns 局 动 成 功 ， 和 运行 正常 ， 但 是 service 之 间 无 法 解析 ，kubernetes 中 的 DNS 解 
DT HE 
解决 方法 


CentOS 中 安装 conntrack-tools 包 后 重启 kubernetes 集 群 即 可 。 


5. Pod stucks in terminating if it has a 
privileged container but has been scheduled to 
a node which doesn't allow privilege 
issue#42568 


当 pod 被 调度 到 无 法 权限 不 足 的 node 上 时 ，pod 一 直 处 于 pending 状 态 ， 且 无 法 删除 
pod， 删 除 时 一 直 处 于 terminating 状 态 。 


kubelet 中 的 报错 信息 


Error validating pod kube-keepalived-vip-1p62d default(5d79ccc0- 

3173-11e7-bfbd-8afie3a7c5bd) from api, ignoring: spec.containers 
[0].securityContext.privileged: Forbidden: disallowed by cluster 
policy 


6.PVC  *I Storage 5 X € iX B f EX 
使 用 glusterfs 做 持久 化 存储 文档 中 我 们 构建 了 PV 和 PVC， 当 时 给 glusterfs- 
nginx 的 PVC 设 置 了 8G 的 存储 限额 ，nginx-dm 这 个 Deployment 使 用 了 该 PVC ， 


进入 该 Deployment 中 的 Pod 执 行 测试 : 


dd if=/dev/zero of=test bs=1G count=10 


|root@nginx-dm-3698525684-gemvt:~# df -h 


Filesystem Size Used Avail Use% Mounted on 
/dev/mapper/docker-8:20-2513719-68fc56b9d12f454a80ef69105f2dc6a42ae8ba81324d51764dbf2710b7da6962e 10G 228M 9.86 3% / 

tmpfs 63G e 63G 0% /dev 

tmpfs 63G e 63G 0% /sys/fs/cgroup 

/dev/sdb4 2.0T 28G 2.0T 2% /etc/hosts 

shm 64M © 64M 0% /dev/shm 
172.20.0.113:k8s-volume 1.0T 0 1.0T 0% /usr/share/nginx/html 
tmpfs 63G 12K 63G 1% /run/secrets/kubernetes.io 
/serviceaccount 


|rootünginx-dm-3698525684-gOmvt:-£ dd if=/dev/zero of=test bs=1G count-11 
dd: error writing 'test': No space left on device 

1040 records in 

9+0 records out 

10486870016 bytes (10 GB) copied, 14.6692 s, 715 MB/s 
rootünginx-dm-3698525684-g0mvt:-4 || 











图 片 - pvc-storage-limit 


从 截图 中 可 以 看 到 创建 了 9 个 size 为 1G 的 block 后 无 法 继续 创建 了 ， 已 经 超出 了 8G 的 
限额 。 


7. 使 用 Headless service 的 时 候 kubedns 解析 不 


kubelet 的 配置 文件 /etc/kubernetes/kubelet 中 的 配置 中 将 集群 DNS 的 
domain name 配置 成 了 --cluster-domain-cluster.local. ， 虽 然 对 于 
service 的 名 字 能 够 正常 的 完成 DNS 解析 ， 但 是 对 于 headless service 中 的 pod 名 
字 解 析 不 了 ， 查 看 pod 的 /etc/resolv.conf 文件 可 以 看 到 以 下 内 容 : 


nameserver 10.0.254.2 

search default.svc.cluster.local. svc.cluster.local. cluster.loc 
al. jimmysong.io 

options ndots:5 


修改 /etc/kubernetes/kubelet 文件 中 的 --cluster- 
domain=cluster.local. 将 local 后 面 的 点 去 掉 后 重启 所 有 的 kubelet， 这 样 新 创 
建 的 pod 中 的 /etc/resolv.conf 文件 的 DNS 配置 和 解析 就 正常 了 


8. kubernetes 集成 ceph 存储 rbd 命令 组 装 问 题 


kubernetes 使 用 ceph 创建 PVC 的 时 候 会 有 如 下 报错 信息 : 


Events: 

FirstSeen LastSeen Count From SubObjec 
tPath Type Reason Message 

1h 12s 441 {persistentvolume-controller } 


Warning ProvisioningFailed Failed to provision 
volume with StorageClass "ceph-web": failed to create rbd image 
: executable file not found in $PATH, command output: 


检查 kube-controller-manager 的 日 志 将 看 到 如 下 错误 信息 


Sep 4 15:25:36 bj-xg-oam-kubernetes-001 kube-controller-manager 
: W0904 15:25:36.032128 13211 rbd util.go:364] failed to creat 
e rbd image, output 

Sep 4 15:25:36 bj-xg-oam-kubernetes-001 kube-controller-manager 
: W0904 15:25:36.032201 13211 rbd util.go:364] failed to creat 
e rbd image, output 

Sep 4 15:25:36 bj-xg-oam-kubernetes-001 kube-controller-manager 
: W0904 15:25:36.032252 13211 rbd util.go:364] failed to creat 
e rbd image, output 

Sep 4 15:25:36 bj-xg-oam-kubernetes-001 kube-controller-manager 
: E0904 15:25:36.032276 13211 rbd.go:317] rbd: create volume f 
ailed, err: failed to create rbd image: fork/exec /usr/bin/rbd: 
invalid argument, command output: 


该 问题 尚未 解决 ， 参 考 Error creating rbd image: executable file not found in 
$PATHZ38923 


9. Helm: Error: no available release name 
found 


在 


in 


这 
建 


开启 了 RBAC 的 kubernetes 集 群 中 ， 当 使 用 helm 部 署 应 用 ， 执 行 helm 
stall 的 时 候 ， 会 报 着 个 错误 : 


Error: no available release name found 
Error: the server does not allow access to the requested resourc 


e (get configmaps ) 


文 是 因为 我 们 使 用 的 2.3.1 版 本 的 helm init 的 时 候 没 有 为 tller 创 


serviceaccount 和 clusterrolebiding 的 缘故 导致 的 。 


kubectl create serviceaccount --namespace kube-system tiller 
kubectl create clusterrolebinding tiller-cluster-rule --clusterr 
ole=cluster-admin --serviceaccount=kube-system: tiller 

# helm init -i harbor-001.jimmysong.io/library/kubernetes-helm-t 
iller:v2.3.1 

kubectl patch deploy --namespace kube-system tiller-deploy -p '{ 
"spec": {"template":{"spec":{"serviceAccount":"tiller"}}}}' 


e Helm: Error: no available release name found - StackOverflow 
e Helm 2.2.3 not working properly with kubeadm 1.6.1 default RBAC rules 
#2224 


Persistent Volume 


Resource Design Proposals 


Helm: Error: no available release name found 
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Kubernetes 版 本 更 新 日 志 
刚 开 始 写作 本 书 时 kubernetes1.6 刚 刚 发 布 ， 随 后 kubernetes 基 本 以 每 3 个 月 发 布 一 
个 版 本 的 速度 不 断 和 迭代， 为 了 追踪 不 同 版 本 的 新 特性 ， 我 们 有 必要 在 此 记录 一 下 。 


每 个 kubernetes 版 本 的 详细 更 新 日 志 请 参 
Æ : https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md 


发 布 记录 


e 2017 年 6 月 29 日 Kubernetes1.7 发 布 
e 2017 年 9 月 28 日 Kubernetes1.8 发 布 
e 2017 年 12 月 15 日 Kubernetes1.9 发 布 


更 多 
追踪 Kubernetes 最 新 特性 ， 请 访问 互动 教学 网 站 提供 商 Katacoda.com 创建 的 
kubernetesstatus.com ° 


Copyright © jimmysong.io 2017-2018 all right reserved > powered by 
GitbookUpdated at 2018-05-09 14:15:47 


Kubernetes1.7 € 3f E 4 


2017 年 6 月 29 日 ，kuberentes1.7 发 布 。 该 版 本 的 kubernetes 在 安全 性 、 存 储 和 可 扩 
展 性 方面 有 了 很 大 的 提升 。 改 版 本 的 详细 更 新 文档 请 查看 Changelog。 


这 些 新 特性 中 包含 了 安全 性 更 高 的 加 密 的 Secret、pod 间 通讯 的 网 络 策略 ， 限 制 
kubelet 访 问 的 节点 授权 程序 以 及 客户 端 /服务 器 TLS 证 书 轮换 。 


对 于 那些 在 Kubernetes 上 运行 横向 扩展 数据 库 的 人 来 说 ， 这 个 版 本 有 一 个 主要 的 特 
性 ， 可 以 为 StatefulSet 添 加 自动 更 新 并 增强 DaemonSet 的 更 新 。 我 们 还 宣布 了 对 本 
地 存储 的 Alpha 支 持 ， 以 及 用 于 更 快 地 缩放 StatefulSets 的 突 发 模式 。 


此 外 ， 对 于 高 级 用 户 ， 此 发 行 版 中 的 AP| 聚 合 允 许 使 用 用 于 自 定义 的 API 与 API 
server 同 时 运行 。 其 他 亮点 包括 支持 可 扩展 的 准 入 控制 器 ， 可 播 拔 云 供 应 商 程序 和 
容器 运行 时 接口 (CRI) 增强 功能 。 


e Network Policy API 提升 为 稳定 版 本 。 用 户 可 以 通过 使 用 网 络 插件 实现 的 网 络 
策略 来 控制 哪些 Pod 之 间 能 够 互相 通信 

e 节点 授权 和 准 入 控制 插件 是 新 增加 的 功能 ， 可 以 用 于 限制 kubelet 可 以 访问 的 
secret、pod 和 其 它 基于 节点 的 对 象 。 

e. 加 窖 的 Secret 和 etcd 中 的 其 它 资源 ， 现 在 是 alpha 版 本 。 

e Kubelet TLS bootstrapping 现 在 支持 客户 端 和 服务 器 端的 证 书 轮换 。 

e WAPI server 存 储 的 审计 日 志 现 在 更 具 可 定制 性 和 可 扩展 性 ， 支 持 事件 过 滤 和 
Webhook。 它们 还 为 系统 审计 提供 更 丰富 的 数据 。 


o 


有 状态 负载 


e StatefulSet 更 新 是 1.7 版 本 的 beta 功 能 ， 它 允许 使 用 包括 滚动 更 新 在 内 的 一 系列 
更 新 策略 自动 更 新 诸如 Kafka，Zookeeper 和 etcd 等 有 状态 应 用 程序 。 

e StatefulSets 现 在 还 支持 对 不 需要 通过 Pod 管 理 策 略 进行 排序 的 应 用 程序 进行 快 
速 扩展 和 局 动 。 这 可 以 是 主要 的 性 能 改进 。 

e 本 地 存储 (alpha) 是 有 状态 应 用 程序 最 常用 的 功能 之 一 。 用 户 现在 可 以 通过 
标准 的 PVC/PV 接 口 和 StatefulSet 中 的 StorageClass 访 问 本 地 存储 卷 。 


e DaemonSet 一 一 为 每 个 节点 创建 一 个 Pod， 现 在 有 了 更 新 功能 ， 在 1.7 中 增加 
了 智能 回 滚 和 历史 记录 功能 。 

e 新 的 StorageOS Volume 插 件 可 以 使 用 本 地 或 附加 节点 存储 中 以 提供 高 可 用 的 
集群 范围 的 持久 卷 。 


可 扩展 性 


e 运行 时 的 AP| 有 聚 合 是 此 版 本 中 最 强大 的 扩展 功能 ， 人 允许 高 级 用 户 将 Kubernetes 
风格 的 预先 构建 的 第 三 方 或 用 户 创建 的 API 添 加 到 其 集群 中 。 

容器 运行 时 接口 (CRI) 已 经 增强 ， 可 以 使 用 新 的 RPC 调 用 从 运行 时 检索 容器 
度量 。CRI 的 验证 测试 已 经 发 布 ， 与 containerd 进 行 了 Alpha 集 成 ， 现 在 支持 基 
本 的 生命 周期 和 镜像 管理 。 参 考 深 入 介绍 CRI 的 文章 。 


e 引入 了 对 外 部 准 入 控制 器 的 Alpha 支 持 ， 提 供 了 两 个 选项 ， 用 于 向 API server% 
加 自 定义 业务 逻辑 ， 以 便 在 创建 对 象 和 验证 策略 时 对 其 进行 修改 。 

e 基于 策略 的 联合 资源 布局 提供 Alpha 版 本 ， 用 于 根据 自 定 义 需求 (如 法 规 、 定 
价 或 性 能 ) 为 联合 (federated) 集群 提供 布局 策略 。 


A R 


e 第 三 方 资源 (TPR) 已 被 自 定义 资源 定义 (Custom Resource Definitions : 
CRD) 取代 ， 后 者 提供 了 一 个 更 清晰 的 API， 并 解决 了 TPR 测试 期 间 引 发 的 问 
题 和 案例 。 如 果 您 使 用 TPR 测试 版 功能 ， 则 建议 您 迁移 ， 因 为 它 将 在 
Kubernetes 1.8 中 被 移 除 。 


以 上 是 Kubernetes1.7 中 的 主要 新 特性 ， 详 细 更 新 文档 请 查看 Changelog 。 


Kuberentes 1.7: Security Hardening, Stateful Application Updates and 
Extensibility 
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Kubernetes1.8# 3, E & 


2017 年 9 月 28 日 ，kubernetes1.8 版 本 发 布 。 该 版 本 中 包括 了 一 些 功 能 改进 和 增强 ， 
并 增加 了 项 目的 成 熟 度 ， 将 强 了 kubernetes 的 治理 模式 ， 这 些 都 将 有 利于 
kubernetes 项 目的 持续 发 展 。 


聚焦 安全 性 


Kubernetes1.8 的 基于 角色 的 访问 控制 (RBAC) 成 为 aud 。RBAC 人 允许 集群 
管理 员 动态 定义 角色 对 于 Kubernetes API 的 访问 策略 。 通 过 网 络 策略 筛选 出 站 流量 
的 Beta 支 持 ， 增 强 了 对 入 站 流量 进行 过 滤 的 现 有 支持 。 Re 网 络 策略 是 强化 
Kubernetes 内 组 织 和 监管 安全 要 求 的 两 个 强大 工具 。 


Kubelet 的 传输 层 安全 性 (TLS) 证 书 轮换 成 为 beta 版 。 自 动 证 书 轮换 减轻 了 集群 安 
全 性 运 维 的 负担 。 


聚焦 工作 负载 支持 


Kubernetes 1.8 通 过 apps/v1beta2 组 和 版 本 推动 核心 工作 负载 API 的 beta 版 本 。Beta 
版 本 包含 当前 版 本 的 Deployment、DaemonSet、ReplicaSet 和 StatefulSet。 工作 
负载 API 是 将 现 有 工作 负载 迁移 到 Kubernetes 以 及 开发 基于 Kubernetes 的 云 原生 应 
用 程序 提供 了 基石 。 


对 于 那些 考虑 在 Kubernetes 上 运行 大 数据 任务 的 ， 现 在 的 工作 负载 API| 支 持 运 行 
kubernetes 原 生 支 持 的 Apache Spark ° 


批量 工作 负载 ， 比 如 夜间 ETL 工 作 ， 将 从 CronJobs 的 beta 版 本 中 受益 。 


自 定 义 资 源 定 义 (CRD) 在 Kubernetes 1.8 中 依然 为 测试 版 。CRD 提 供 了 一 个 强大 
的 机 制 来 扩展 Kubernetes 和 用 户 定义 的 API 对 象 。 CRD 的 一 个 用 例 是 通过 Operator 
Pattern 自 动 执行 复杂 的 有 状态 应 用 ， 例 如 键 值 存储 、 数 据 库 和 存储 引擎 。 随 着 稳定 
性 的 继续 推进 ， 预 计 将 继续 加 强 对 CRD 的 验证 。 


LG 


Volume lk ` PVA X] > A zbtaint ^ pod 7A ` kubectld& t+ + ! 
除了 稳定 现 有 的 功能 ，Kubernetes 1.8 还 提供 了 许多 预览 新 功能 的 alpha 版 本 。 


社区 中 的 每 个 特别 兴趣 小 组 (SIG) 都 在 继续 为 所 在 领域 的 用 户 提供 更 多 的 功能 。 
有 关 完 整 列表 ， 请 访问 发 行 说 明 。 


Kubernetes 1.8: Security Workloads and Feature Depth 
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Kubernetes1.9 更 新 日 志 


2017 年 12 月 15 日 ，kubernetes1.9 版 本 发 布 。Kubernetes 依 然 按 照 每 三 个 月 一 个 大 
版 本 发 布 的 速度 稳定 迭代 ， 这 是 今年 发 布 的 第 四 个 版 本 ， 也 是 今年 的 最 后 一 个 版 
本 ， 该 版 本 最 大 的 MP E Workloads APIA BR ZMA > RHR TAR E TR dpt 
户 对 于 该 功能 稳定 性 的 担忧 。 还 有 一 个 重大 更 新 ， 就 是 测试 支持 了 Windows 了 ， 
打开 了 在 kubernetes 中 运行 Windows 工 作 负 载 的 大 门 。 


Workloads API GA 


apps/v1 Workloads API 成 为 GA (General Availability) ， 且 默认 启用 。 Apps 
Workloads API 将 DaemonSet、Deployment、ReplicaSet 和 StatefulSet API 组 合 
在 一 起 ， 作 为 Kubernetes 中 长 时 间 运 行 的 无 状态 和 有 状态 工作 负载 的 基础 。 


Deployment 和 ReplicaSet 是 Kubernetes 中 最 常用 的 两 个 对 象 ， 经 过 一 年 多 的 实际 使 
用 和 反馈 后 ， 现 在 已 经 趋 于 稳定 。SIG apps 同 时 将 这 些 经 验 应 用 到 另外 的 两 个 对 象 
上 ， 使 得 DaemonSet 和 StatefulSet 也 能 顺利 毕业 走向 成 熟 。v1 (GA) 意味 着 已 经 
生产 可 用 ， 并 保证 长 期 的 向 后 兼容 。 


Windows 支 持 (beta) 


Kubernetes 最 初 是 为 Linux 系 统 开发 的 ， 但 是 用 户 逐 渐 意识 到 容器 编排 的 好 处 ， 我 
们 看 到 有 人 需要 在 Kubernetes 上 运行 Windows 工 作 负 载 。 在 12 个 月 前 ， 我 们 开始 认 
真 考虑 在 Kubernetes 上 Wndows Server 的 工作 。 SIG-Windows 现 在 已 经 将 这 
个 功能 推广 到 beta 版 本 ， 这 意味 着 我 们 可 以 评估 它 的 使 用 情况 。 


增强 存储 


kubernetes 从 第 一 个 版 本 开始 就 支持 多 种 持久 化 数据 存储 ， 包 括 常 用 的 NFS 或 
iSCSI， 以 及 对 主要 公共 云 和 私有 云 提供 商 的 存储 解决 方案 的 原生 支持 。 随 着 项 目 
和 生态 系统 的 发 展 ，Kubernetes 的 存储 选择 越 来 越 多 。 然 而 ， 为 新 的 存储 系统 添加 
volume 插 件 一 直 是 一 个 挑战 。 


容器 存储 接口 (CSI) 是 一 个 跨行 业 标准 计划 , TERRAM 生存 储 开 发 的 障碍 并 
确保 兼容 性 。 SIG-Storage 和 CSI 社 区 正在 合作 提供 一 个 单一 接口 ， 用 于 配置 、 附 
着 和 挂 载 与 Kubernetes 兼 容 的 存储 。 


Kubernetes 1.9 引 入 了 容器 存储 接口 (CSI) 的 alpha 实 现 ， 这 将 使 挂 载 新 的 volume 
插件 就 像 部 署 一 个 pod 一 样 简单 ， 并 且 第 三 方 存储 提供 商 在 开发 他 们 的 解决 方案 时 
也 无 需 修 改 kubernetes 的 核心 代码 。 


由 于 该 功能 在 1.9 版 本 中 为 alpha， 因 此 必须 明确 启用 该 功能 ， 不 建议 用 于 生产 使 

用 ， 但 它 为 更 具 扩 展 性 和 基于 标准 的 Kubernetes 存 储 生 态 系 统 提 供 了 清晰 的 路 线 

图 o 

其 它 功能 

自 定 义 资 源 定 义 (CRD) 校 验 ， 现 在 已 经 成 为 beta， 默 认 情 况 下 已 启用 ， 可 以 用 来 
帮助 CRD 作 者 对 于 无 效 对 象 定 义 给 出 清晰 和 即时 的 反馈 。 


SIG Node 硬 件 加 速 器 转向 alpha， 启 用 GPU， 从 而 实现 机 器 学 习 和 其 他 高 性 能 工作 


CoreDNS alpha 可 以 使 用 标准 工具 来 安装 CoreDNS 。 
kube-proxy 的 IPVS 模 式 进入 beta 版 ， 为 大 型 集群 提供 更 好 的 可 扩展 性 和 性 能 。 


社区 中 的 每 个 特别 兴趣 小 组 (SIG) 继续 提供 其 所 在 领域 的 用 户 最 迫切 需要 的 功 
能 。 有 关 完 整 列表 ， 请 访问 发 行 说 明 。 


3 
获取 
Kubernetes1.9 已 经 可 以 通过 GitHub 下 载 。 


参考 


Kubernetes 1.9: Apps Workloads GA and Expanded Ecosystem 
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Kubernetes1.10 # 3 A & 
2018 年 3 月 26 日 ，kubernetes1.10 版 本 发 布 ， 这 是 2018 年 发 布 的 第 一 个 版 本 。 该 版 
本 的 Kubernetes 主 要 提升 了 Kubernetes 的 成 熟 度 、 可 扩展 性 与 可 插入 性 。 


该 版 本 提升 了 三 大 关键 性 功能 的 稳定 度 ， 分 别 为 存储 、 安 全 与 网 络 。 另 外 ， 此 次 新 
版 本 还 引入 了 外 部 kubectl 赁 证 提供 程序 (处 于 alpha 测 试 阶段 ) 、 在 安装 时 将 默认 
的 DNS 服务 切换 为 CoreDNS (beta 测 试 阶段 ) 以 及 容器 存储 接口 (简称 CSI) 与 持 
久 化 本 地 卷 的 beta 测 试 版 。 


下 面 再 分 别 说 下 三 大 关键 更 新 。 


存储 


e CSI (容器 存储 接口 ) 迎 来 Beta 版 本 ， 可 以 通过 插件 的 形式 安装 存储 。 

e 持久 化 本 地 存储 管理 也 迎 来 Beta 版 本 。 

e 对 PV 的 一 系列 更 新 ， 可 以 自动 阻止 Pod 正 在 使 用 的 PVC 的 删除 ， 阻 止 已 绑 定 到 
PVC 的 PV 的 删除 操作 ， 这 样 可 以 保证 所 有 存储 对 象 可 以 按照 正确 的 顺序 被 删 
KR o 


安全 
e kubectl 可 以 对 接 不 同 的 凭证 提供 程序 


e 各 云 服 务 供 应 商 、 厂 商 以 及 其 他 平台 开发 者 现在 能 够 发 布 二 进 制 插件 以 处 理 特 
定 云 供应 商 |AM 服 务 的 身价 验证 


e 将 原来 的 kube-dns 切 换 为 CoreDNS 


获取 


Kubernetes1.10 已 经 可 以 通过 GitHub 下 载 。 


> 


5 


Kubernetes 1.10: Stabilizing Storage, Security, and Networking 
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Kubernetes X ax t EZ 25 A EE 


本 节 将 聚焦 Kubernetes 及 云 原生 技术 的 年 度 总 结 并 展望 下 一 年 的 发 展 。 
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Kubernetes 5 &/® 4.20174 44.445 7&4 2018 
年 展望 


本 文 主要 关于 Kubernetes 及 云 原 生生 态 圈 在 2017 年 取得 的 进展 ， 及 对 2018 年 的 展 


云 计 算 技术 发 展 至 今 已 经 10 多 个 年 头 了 ， 从 最 开始 的 硬件 虚拟 化 、laaS、 
OpenStack、PaaS、 容 器 设置 到 Serverless 发 展 至 今 ， 已 经 越 来 约 接 近 应 用 逻辑， 
容器 实现 了 应 用 的 分 装 ， 方 便 了 应 用 在 不 同 环境 问 的 迁移 ， 轻 量 级 的 特性 又 使 它 能 
够 消耗 更 少 的 资源 而 带 来 更 多 的 便利 ， 但 是 独 木 难 支 ， 容 器 如 果 在 单 节 点 上 运行 并 
不 能 发 挥 它 的 最 大 效益 ， 容 器 编排 领域 在 2016 年 就 成 为 了 兵家 必 争 之 地 。 在 新 的 一 
年 即将 到 来 时 ， 本 文 将 带 您 一 起 梳理 2017 年 Kubernetes 及 云 原 生 的 发 展 ， 并 对 其 在 
2018 年 的 趋势 作出 预测 。 


Kubernetes 


谈 到 oe 就 不 得 不 谈 到 容器 ， 
大 家 说 容器 通常 是 指 Docker 容 器 ， 其 
P ds 导 使 用 容器 。 


容器 从 几 年 前 的 大 热 到 现在 的 归于 平淡 ， 之 前 
至 很 多 人 就 将 容器 等 同 于 Docker， 还 有 很 多 人 


Kubernetes 是 谷歌 根据 其 内 部 使 用 的 Borg 改 造成 一 个 通用 的 容器 编排 调度 器 ， 于 
2014 年 将 其 发 布 到 开源 社区 ， 并 于 2015 年 将 其 捐赠 给 Linux 基 金 会 的 下 属 的 云 原生 
计算 基金 会 (CNCF) ， 也 是 GIFEE (Google Infrastructure For Everyone Else) 
中 的 一 员 ， 其 他 还 包括 HDFS、Hbase、Zookeeper 等 ， 
https://github.com/GIFEE/GIFEE * a ee 
展 史 。 


Kubernetes 发 展 历史 


相信 凡是 关注 容器 生态 圈 的 人 都 不 会 否认 ，Kubernetes 已 经 成 为 容器 编排 调度 的 实 
际 标准 ， 不 论 Docker 官 方 还 是 Mesos 都 已 经 支持 Kubernetes，Docker 公 司 在 今年 
10 月 16 日 至 19 日 举办 的 DockerCon EU 2017 大 会 上 宣布 支持 Kubernetes 调 度 ， 就 
在 这 不 久 前 Mesos 的 商业 化 公司 Mesosphere 的 CTO Tobi Knaup 也 在 官方 博客 中 宣 
布 Kubernetes on DC/OS。 而 回想 下 2016 年 时 ， 我 们 还 在 为 Swarm、Mesos、 


Kubernetes 谁 能 够 在 容器 编排 调度 大 战 中 胜出 而 猜测 时 ， 而 经 过 不 到 一 年 的 发 展 ， 

Kubernetes 就 以 超过 70% 的 市 场 占 有 率 ( 据 TheNewStack 的 调研 报告 ) 将 另外 两 者 
遂 遥 的 甩 在 了 身后 ， 其 已 经 在 大 量 的 企业 中 落地 ， 还 有 一 些 重量 级 的 客户 也 宣布 将 
服务 迁移 到 Kubernetes 上 ， 比 如 GitHub ( 见 Kubernetes at GitHub) ， 还 有 eBay、 

彭 博 社 等 。 


Kubernetes 自 2014 年 由 Google 开 源 以 来 ， 至 今 已 经 发 展 到 了 1.9 版 本 ， 下 面 是 
Kubernetes 的 版 本 发 布 路 线 图 : 


e 2014 年 10 月 由 Google 正 式 开源 。 

e 2015 年 7 月 22 日 发 布 1.0 版 本 ， 在 OSCON (开源 大 会 ) 上 发 布 了 1.0 版 本 。 

e 2015 年 11 月 16 日 发 布 1.1 版 本 ， 性 能 提升 ， 改 进 了 工具 并 创建 了 日 益 强 大 的 社 
区 o 

e 2016 年 4 月 16 日 发 布 1.2 版 本 ， 更 多 的 性 能 升级 加 上 简化 应 用 程序 部 署 和 管理 。 

e 2016 年 7 月 22 日 发 布 1.3 版 本 ， 对 接 了 云 原生 和 企业 级 工作 负载 。 

e 2016 年 9 月 26 日 发 布 1.4 版 本 ， 该 版 本 起 Kubernetes 开 始 支 持 不 同 的 运行 环境 ， 
并 使 部 署 变 得 更 容易 。 

e 2016 年 12 月 13 日 发 布 1.5 版 本 ， 该 版 本 开始 支持 生产 级 别 工作 负载 。 

e 2017 年 3 月 28 日 发 布 1.6 版 本 ， 该 版 本 支持 多 租户 和 在 集群 中 自动 化 部 署 不 同 的 

e 2017 年 6 月 29 日 发 布 1.7 版 本 ， 该 版 本 的 kubernetes 在 安全 性 、 存 储 和 可 扩展 性 
方面 有 了 很 大 的 提升 。 

e 2017 年 9 月 28 日 发 布 1.8 版 本 ， 该 版 本 中 包括 了 一 些 功 能 改进 和 增强 ， 并 增加 了 
项 目的 成 熟 度 ， 将 强 了 kubernetes 的 治理 模式 ， 这 些 都 将 有 利于 kubernetes 项 
目的 持续 发 展 。 

e 2017 年 12 月 15 日 发 布 1.9 版 本 ， 该 版 本 最 大 的 oe i Workloads API 成 为 
稳定 版 本 ， 这 消除 了 很 多 潜在 用 户 对 于 该 功能 稳定 性 的 担忧 。 还 有 一 个 重大 更 
新 ， 就 是 测试 支持 了 Windows 了 ， Rico utentes = ffWindows - 1E 
负载 的 大 门 。 


从 上 面 的 时 间 线 中 我 们 可 以 看 到 ，Kubernetes 的 产品 迭代 周期 越 来 越 快 ， 从 2014 年 
开源 ，2015 年 发 布 了 两 个 版 本 ，2016 年 发 布 了 三 个 版 本 ， 而 今年 一 年 内 就 发 布 了 4 
个 大 版 本 ，Kubernetes 已 经 变 了 的 越 来 越 稳定 ， 越 来 越 易 用 。 


Kubernetes 的 架构 做 的 足够 开放 ， 通 过 系列 的 接口 ， 如 CRI (Container Runtime 
Interface) 作为 Kubelet 与 容器 之 问 的 通信 接口 、CNI〈Container Networking 
Interface) 来 管理 网 络 、 而 持久 化 存储 通过 各 种 Volume Plugin 来 实现 ， 同 时 


Kubernetes 4 APIA Jr 4 T 438 it CRD (Custom Resource Define) 来 扩展 ， 还 可 
以 自己 编写 Operator 和 Service Catalog 来 基于 Kubernetes 实 现 更 高 级 和 复杂 的 功 


FAG) 
月 已 


Cloud Native 


在 Kubernetes 出 现 之 前 ， 就 已 经 有 人 提出 了 云 原 生 的 概念 ， 如 2010 年 Paul 
Fremantle 就 在 他 的 博客 中 提出 了 云 原生 的 核心 理念 ， 但 是 还 没有 切实 的 技术 解决 
方案 。 而 那 时 候 PaaS 才 刚刚 出 现 ，PaaS 平 台 提 供 商 Heroku 提 出 了 12 因 素 应 用 的 理 
念 ， 为 构建 SaaS 应 用 提供 了 方法 论 ， 该 理念 在 云 原生 时 代 依 然 适 用 。 


现 如 今 云 已 经 可 以 为 我 们 提供 稳定 的 可 以 唾 手 可 得 的 基础 设施 ， 但 是 业务 上 云 成 了 
一 个 难题 ，Kubernetes 的 出 现 与 其 说 是 从 最 初 的 容器 编排 解决 方案 ， 倒 不 如 说 是 为 
了 解决 应 用 上 云 ( 即 云 原生 应 用 ) 这 个 难题 。CNCF 中 的 托管 的 一 系列 项 目 即 致力 
于 云 原 生 应 用 整个 生命 周期 的 管理 ， 从 部 署 平台 、 日 志 收 集 、Service Mesh (服务 
网 格 ) 、 服 务 发 现 、 分 布 式 追踪 、 监 控 以 及 安全 等 各 个 领域 通过 开源 的 软件 为 我 们 
提供 一 揽 子 解决 方案 。 


外 已 经 有 众多 的 Kubernetes 和 Cloud Native meetup 定 期 举办 ， 在 中 国 今年 可 以 


说 是 小 荷 才 露 尖 尖 角 。 

e 2017 年 6 月 19 日 -20 日 ， 北 京 ，L3 大 会 (LinuxCon+ContainerCon+CloudOpen 
China) 。CNCF (Cloud Native Computing Foundation ) 作为 云 原 生 应 用 的 
联合 推广 团体 ， 也 是 由 Google 一 手 培植 起 来 的 强大 "市场 媒 体 ”(Kubernetes 是 
第 一 个 入 选 该 基金 会 的 项 目 ) ， 第 一 次 进入 中 国 ， 华 为 、Google、Rancher、 
红 帆 等 公司 分 别 做 了 关于 Kubernetes 及 Cloud Native 的 演讲 。 

e 2017 年 7 月 25 日 ， 北 京 、 上 海 ，k8smeetup，Kubernetes 二 周年 北京 -上 海 
Meetup 双 城 庆生 。 

e 2017 年 9 月 12 日 ， 北 京 ，T11 大 会 ， 前 Pivotal 技 术 专 家 ， 现 CapitalOne 高 级 专 
家 Kevin Hoffman 做 了 High Level Cloud Native Concepts 的 演讲 。 

e 2017 年 10 月 15 日 ， 杭 州 ，KEUC 2017- Kubernetes 中 国 用 户 大 会 。 由 才 云 科 
技 (Caicloud) 、 美 国 The Linux Foundation 基金 会 旗下 Cloud Native 
Computing Foundation (CNCF)、 [TK8sMeetup 中 国 社 区 」 联合 主 办 的 聚焦 
Kubernetes 中 国 行业 应 用 与 技术 落地 的 盛会 。 

e 2017 年 12 月 13 日 -15 日 ， 杭 州 ， 云 原生 技术 大 会 一 一 CNTC。 这 次 会 议 由 谐 云 
科技 与 网 萝 云 共同 主办 ， 主 要 探讨 云 原 生 技 术 与 应 用 ， 同 时 还 进行 了 云 原 生 集 
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另外 还 有 由 才 云 科技 分 别 在 北京 、 上 海 、 深 圳 、 青 岛 等 地 举办 了 多 场 k8smeetup 。 


容器 是 云 原生 的 基石 


容器 最 初 是 通过 开发 者 工具 而 流行 ， 可 以 使 用 它 来 做 隔离 的 开发 测试 环境 和 持续 集 
成 环境 ， 这 些 都 是 因为 容器 轻 量 级 ， 多 于 配置 和 使 用 带 来 的 优势 ，docker 和 docker- 
compose 这 样 的 工具 极 大 的 方便 的 了 应 用 开发 环境 的 搭建 ， 同 时 基于 容器 的 Cl/CD 
工具 如 雨后春笋 般 出 现 。 


隔离 的 环境 、 良 好 的 可 移植 性 、 模 块 化 的 组 件 、 易 于 扩展 和 轻 量 级 的 特性 ， 使 得 容 
器 成 为 云 原生 的 基石 。 但 是 容器 不 光 是 docker 一 种 ， 还 有 cri-o、rkt 等 支持 OCI 标 准 
的 容器 ， 以 及 OpenStack 基 金 会 推出 的 兼容 容器 标准 的 号 称 是 轻 量 级 虚拟 机 的 Kata 
Containers，Kubernetes 并 不 绑 定 到 某 一 容器 引擎 ， 而 是 支持 所 有 满足 DCI 运 行 时 
标准 的 容器 。 


FORA 


Google 通 过 将 云 应 用 进行 抽象 简化 出 的 Kubernetes 中 的 各 种 概念 对 和 象 ， 如 Pod ` 
Deployment、Job、StatefulSet 等 ， 形 成 了 Cloud Native 应 用 的 通用 的 可 移植 的 模 
型 ，Kubernetes 作 为 云 应 用 的 部 署 标 准 ， 直 接 面 向 业务 应 用 ， 将 大 大 提高 云 应 用 的 
可 移植 性 ， 解 决 云 厂 商 锁定 的 问题 ， 让 云 应 用 可 以 在 跨 云 之 间 无 颖 迁移 ， 其 至 用 来 
管理 混合 云 ， 成 为 企业 |T 云 平台 的 新 标准 。 


现状 及 影响 

Kubernetes 既 然 是 下 一 代 云 计算 的 标准 ， 那 么 它 当 前 的 现状 如 何 ， 距 离 全 面 落 地 还 
有 存在 什么 问题 ? 

当前 存在 的 问题 


如 果 Kubernetes 被 企业 大 量 采 用 ， 将 会 是 对 企业 IT 价值 的 重 塑 ，|T 将 是 影响 业务 速 
度 和 健壮 性 的 中 流 丰 柱 ， 但 是 对 于 Kubernetes 夏 正 落地 还 存在 诸多 问题 : 


e 部 署 和 运 维 起 来 复杂 ， 需 要 有 经 过 专业 的 培训 才能 掌握 ; 
e 企业 的 组 织 架构 需要 面向 DevOps 转 型 ， 很 多 问题 不 是 技术 上 的 ， 而 是 管理 和 
心态 上 的 ; 


e 对 于 服务 级 别 尤 其 是 微服 务 的 治理 不 足 ， 暂 没有 一 套 切 实 可 行 可 落地 的 完整 微 
服务 治理 方案 ; 

e ee 

e 当前 很 多 传统 应 用 可 能 不 适 
落地 的 项 目 不 多 影响 推广 ; 


善 ， 需 要 编写 配置 大 量 的 YAML 文 件 ， 难 于 管理 ; 
合 迁 移 到 Kuberentes， 或 者 是 成 本 太 高 ， 因 此 可 以 


以 上 这 些 问 题 是 企业 站 正 落地 Kubernetes 时 将 会 遇 到 的 比较 坏 手 的 问题 ， 针 对 这 些 
问题 ，Kubernetes 社 区 早 就 心领神会 有 多 个 SIG) (Special Interest Group) 专门 负 
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日 益 强 大 的 社区 


Kubernetes 已 成 为 GitHub 上 参与 和 讨论 人 数 最 多 的 开源 项 目 ， 在 其 官方 Slack 上 有 
超过 两 万 多 名 注册 用 户 (其 中 包括 中 文 用 户 频道 cn-users) ;而 整个 Kubernetes 中 
文 用 户 群 可 达 数 千 名 之 众 。 


目前 关于 Kubernetes 和 云 原 生 图 书 也 已 经 琳 琳 总 总 ， 让 人 眼花 练 乱 。 


英文 版 的 讲解 Kubernetes 的 书籍 有 : The Kubernetes Book ` Kubernetes in 
Action、Kubernetes Microservices with Docker， 关 于 云 原 生 架 构 的 Cloud Native 
Infrastructure: Patterns for Scalable Infrastructure and Applications in a Dynamic 
Environment 等 已 发 行 和 2018 年 即将 发 行 的 有 十 几 本 之 多 ， 同 时 还 有 关于 云 原生 开 
A 85 b FH x, SEX HG * 4eCloud Native Go (这 本 书 已 经 被 翻译 成 中 文 ， 由 电子 工业 
出 版 社 引 进出 版 )、Cloud Native Python (已 由 电子 工业 出 版 社 引 进 ， 预 计 2018 年 
推出 中 文 版 ) * Cloud Native Java 等 。 


关于 Kuberentes 和 云 原生 的 中 文 版 的 书籍 有 : 《Kubernetes 权 威 指南 :从 Docker 到 
Kubernetes 实 践 全 接触 》，《Java 云 原生 》 (预计 2018 年 出 版 ) ， 还 有 一 系列 开 
源 的 电子 书 和 教程 ， 比 如 我 写 的 kubernetes-handbook， 同 时 Kubernetes 官 方 官网 
文档 也 即将 推出 完整 的 汉化 版 本 ， 该 项 目 目前 还 在 进行 中 ， 见 kubernetes-docs- 
cn。 


另外 ， 除 了 图 书 和 官方 Slack 外 ， 在 中 国 还 有 很 多 厂商 、 社 区 、 爱 好 者 组 织 的 
meetup、 微 信和 群 推广 Kubernetes， 同 时 吸引 了 大 量 的 用 户 关注 和 使 用 
Kubernetes ° 


创业 公司 与 厂商 支持 


3+ 8) Google#) GKE ^ 44x #4 Azure ACS、AWS 的 Fargate 和 2018 年 即将 推出 的 
EKS、Rancher 联 合 Ubuntu 推 出 的 RKE， 国 内 的 华为 云 、 BAAS 阿里 云 等 都 已 推 

出 了 公有 云 上 的 Kuberentes 服 务 ，Kubernetes 已 经 成 为 公有 云 的 容器 部 署 的 标 配 ， 
私有 云 领域 也 有 众多 厂商 在 做 基于 Kubernetes 的 PaaS 平 台 。 随 着 企业 落地 
Kubernetes 的 日 益 增 长 ， 相 关 的 人 才 缺 口 也 将 日 益 显现 。CNCF 又 就 此 推出 了 
CKA (Certified Kubernetes Administrator) 和 CKD (Certified Kubernetes 
Developer) ， 假 若 在 Kubernetes 的 生态 构建 与 市 场 发 展 顺利 的 情况 下 ， 该 证 书 将 
会 展现 其 含金量 。 


另外 在 国外 还 有 一 大 批 基于 Kubernetes 的 创业 公司 ， 如 Kubernetes 创 始 人 之 一 Joe 
Beda 创 立 了 Heptio (于 今年 9 月 获 获 得 2500 万 美元 B 轮 融资 ) ， 还 有 Platform9、 
Kismatic、Diamanti、Bitnami、CoreOS、Hypernetes、Weave、NavOps 等 ， 他 
们 中 有 的 提供 Kubernetes 的 技术 咨询 和 培训 ， 有 的 专 研 某 项 具体 技术 ， 还 有 一 系列 
基于 Kubernetes 的 自动 化 工具 、 监 控 厂 商 如 雨后春笋 般 出 现 。 


国内 前 几 年 诞生 了 多 家 容器 创业 公司 ， 例 如 DaoCloud、 ae 、 时 速 云 、 数 人 
云 、 灵 乱 云 、 有 容 云 、 好 雨 云 、 硕 云 、 才 云 、 博 云 等 ， 这 些 厂 商 有 的 可 能 一 开始 不 
是 基于 Kubernetes 作 为 容器 编排 调度 mal > (CIE CASB LS RPREAT 
11488 FRAG MAE ARAL BAL RUE 。 这 些 容 器 厂商 全 部 涉及 私有 云 业务 ， 主 要 对 接 
金融 、 政 府 和 电信 行业 ， 帮 助 传统 企业 进行 IT 转型 ， 虽 然 很 多 厂商 都 生成 支持 
Kubernetes， 但 是 在 Kubernetes 的 易 用 性 上 还 需要 很 多 改进 ， 单 纯 基 于 容器 部 署 应 
用 已 经 无 法 满足 企业 的 需求 ， 帮 助 企 业 上 云 、 将 传统 应 用 改造 以 适应 云 的 弹性 与 高 
效 ， 构 建 PaaS 平 台 ， 通 过 基于 容器 的 基础 调度 平台 运行 大 数据 及 Al 应 用 ， 成 为 创业 
公司 的 众矢之的 ， 对 于 特定 行业 的 整体 的 解决 方案 将 是 国内 的 容器 厂商 的 主要 商业 
化 方式 。 


目前 大 部 分 容器 云 提供 的 产品 大 同 小 异 ， 从 云 平台 管理 、 容 器 应 用 的 生命 周期 管 
理 、DevOps、 微 服务 架构 等 ， 这 些 大 多 是 对 原 有 应 用 的 部 署 和 资源 申请 流程 的 优 
化 ， 没 有 形成 杀手 级 的 平台 级 服务 ， 这 些 都 是 原来 容器 时 代 的 产物 。 而 容器 云 进化 
到 高 级 阶段 Cloud Native ( 云 原生 ) 后 ， 容 器 技术 将 成 为 该 平台 的 基础 ， 虽 然 大 家 
都 生成 具有 全 面 的 功能 ， 但 是 厂商 在 推行 容器 技术 时 需要 结合 企业 的 具体 应 用 场景 
下 进行 优化 。 
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2017 年 可 以 说 是 Cloud Nativezé 3) A J& fe KHZ > Kuberentes % 3x — 4E F 3 
续 发 布 了 4 个 版 本 ， 从 1.6 到 1.9，Containerd、Fluentd、CoreDNS、Jeager 分 别 发 
布 自己 的 1.0 版 本 。 


在 今年 12 月 的 KubeCon&CloudNativeCon Austin 会 议 上 ， 已 经 为 2018 年 的 云 原生 
生态 圈 的 发 展 确定 几 大 关键 词 : 


e 服务 网 格 (Service Mesh) ， 在 Kubernetes 上 践 行 微服 务 架 构 进 行 服务 治理 所 
必须 的 组 件 ; 

e 无 服务 器 架构 (Serverless) ， 以 FaaS 为 代表 的 无 服务 器 架 

e 加 强 数 据 服 务 承载 能 力 ， 例 如 在 Kubernetes 上 运行 大 数据 应 用 ; 

e 简化 应 用 部 署 与 运 维 包括 云 应 用 的 监控 与 日 志 收集 分 析 等 ; 


这 些 功能 是 Kubernetes 生 态 已 有 但 是 玛 待 加 强 的 功能 ， 它 们 能 够 解决 我 们 在 上 文中 
提 到 的 当前 生态 中 存在 的 问题 。 


2018 年 的 laaS 的 运营 商 将 主要 提供 基础 架构 服务 ， 如 虚拟 机 、 存 储 和 数据 库 等 传统 
的 基础 架构 和 服务 ， 仍 然 会 使 用 现 有 的 工具 如 Chef、Terraform、Ansible 等 来 管 

理 ; Kubernetes 则 可 能 直接 运行 在 裸 机 上 运行 ， 结 合 Cl/CD 成 为 DevOps 的 得 力 工 
具 ， 并 成 为 高 级 开发 人 员 的 应 用 部 署 首选 ; Kubernetes 也 将 成 为 PaaS 层 的 重要 组 
成 部 分 ， 为 开发 者 提供 应 用 程序 部 署 的 简单 方法 ， 但 是 开发 者 可 能 不 会 直接 与 
Kubernetes 或 者 PaaS 交 互 ， 实 际 的 应 用 部 署 流程 很 可 能 落 在 自动 化 Cl 工具 如 
Jenkins 上 。 


2018 年 ，Kubernetes 将 更 加 稳定 好 用 ， 云 原生 将 会 出 现 更 多 的 落地 与 最 佳 实 践 ， 这 
都 值得 我 们 期 待 ! 
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Kubernetes 认 证 服务 提供 商 (KCSP) 


云 原 生计 算 基金 会 (CNCF) 负责 维护 并 整合 Kubernetes 和 Prometheus 之 类 的 开源 
技术 ， 今 天 它 在 开源 峰会 上 宣布 了 22 多 家 Kubernetes 认 证 服务 提供 商 (KCSP) 的 

创始 成 员 名单 。KCSP 是 通过 初审 的 企业 组 织 ， 它 们 在 帮助 企业 成 功 地 采用 
Kubernetes 方 面 有 着 丰富 经 验 。 此 外 ， 专 业 人 员 个 人 现在 可 以 注册 报名 新 的 认证 
Kubernetes 管 理 员 (CKA) 计划 和 考试 。KCSP 的 创始 成 员 包 括 CNCF 和 Linux 基 金 
会 的 下 列 成 员 : RAH ` L ` Bitnami ` Canonical ` Container Solutions ` 
CoreOS ` Ghostcloud ` Giant Swarm ` Heptio ` 4# 4 ` IBM ` inwinSTACKInc. ` 
LiveWyer ` Mirantis > RX- M LLC ` =# SDS ` Slackpolnicloue 、Supergiant 和 
Treasure Data » KCSP 计 划 的 适用 对 象 是 通过 初审 的 服务 提供 商 ， 它 们 为 踏 上 
Kubernetes 之 旅 的 公司 企业 提供 Kubernetes 支 持 、 咨 询 、 专 业 服 务 和 培训 。KCSP 
a 从 而 比 以 前 更 迅速 、 更 高 效 地 部 署 新 的 应 用 

序 ， 同 时 确保 有 一 家 值得 信赖 、 经 过 审查 的 合作 伙伴 可 以 支持 其 生产 和 运营 方面 
ee 。 想 成 为 KCSP， 需 要 至 少 三 名 工程 师 通 过 认证 Kubernetes 管 理 员 CKA X 
试 ， 能 够 证 明 在 Kubernetes 社 区 从 事 活动 (包括 积极 贡献 代码 ) ， 以 及 支持 企业 最 
终 用 户 的 商业 模式 ， 包 括 将 工程 师 派驻 客户 现场 。 


参考 CNCF 宣布 首 批 Kubernetes 认证 服务 提供 商 


认证 Kubernetes 管 理 员 (CKA) 


这 是 CNCF 的 官方 认证 ,详情 请 看 官方 介绍 


认证 详情 
在 3~4 小 时 内 用 命令 行进 行 排 障 ， 解 决 问题 ， 相 关 知 识 点 和 权重 


e Installation, Configuration & Validation 安装 ， 配 置 和 验证 12% 
o 设计 一 个 k8s 集群 
o 安装 k8s master 和 nodes 
o 配置 安全 的 集群 通信 
o 配置 高 可 用 的 k8s 集 群 
o 知道 如 何 获取 k8s 的 发 行 的 二 进 制 文件 


o 提供 底层 的 基础 措施 来 部 署 一 个 集群 
o d ae 
o 选择 你 的 基础 设施 配置 
o 在 你 的 集群 上 配置 端 对 端的 测试 
o 分 析 端 对 端 测 试 结 果 
o 运行 节点 的 端 对 端 测 试 
e Core Concepts 核心 概念 19% 
o 理解 k8s api/s i 
o 理解 k8s 架构 
o 理解 services 和 其 它 网 络 相关 原 语 
e Application Lifecycle Management 应 用 生命 周期 管理 8% 
o 理解 Deployment ， 并 知道 如 何 进行 rolling update 和 rollback 
o 知道 各 种 配置 应 用 的 方式 
o 知道 如 何 为 应 用 扩容 
o 理解 基本 的 应 用 自 愈 相关 的 内 容 
e Networking 网 络 11% 
o 理解 在 集群 节点 上 配置 网 络 
o 理解 pod 的 网 络 概念 
o 理解 service networking 
o 部 署 和 配置 网 络 负载 均衡 器 
o 知道 如 何 使 用 ingress 规则 
o 知道 如 何 使 用 和 配置 cluster dns 
o 理解 CN| 
e Storage 存储 7% 
o 理解 持久 化 卷 (pv) ， 并 知道 如 何 创建 它们 
o 理解 卷 (volumes) “access mode 
o 理解 持久 化 卷 声明 (pvc) 的 原 语 
o 理解 k8s 的 存储 对 象 (kubernetes storage objects ) 
o 知道 如 何 为 应 用 配置 持久 化 存储 
e Scheduling 调度 5% 
o 使 用 label 选 择 器 来 调度 pods 
o 理解 Daemonset 的 角色 
o 理解 resource limit 会 如 何 影 响 pod 调度 
o 理解 如 何 运 行 多 个 调度 器 ， 以 及 如 何 配置 pod 使 用 它们 
o 不 使 用 调度 器 ， 手 动 调度 一 个 pod 
o bah LEAR 度 事件 events 


o 知道 如 何 配置 kubernetes scheduler 

e Security 安全 12% 

o 知道 如 何 配置 认证 和 授权 

o 理解 k8s 安 全 相关 原 语 

o 理解 如 何 配置 网 络 策略 (network policies ) 

o 配合 使 用 镜像 的 安全 性 

o 定义 安全 上 下 文 

o 安全 的 持久 化 保存 键 值 
Cluster Maintenance 集群 维护 11% 

o 理解 k8s 的 集群 升级 过 程 

o 促进 操作 系统 的 升级 

o 补充 备份 和 还 原 的 方法 论 
Logging / Monitoring 日 志 / 监 控 5% 

o 理解 如 何 监控 所 有 的 集群 组 件 

o 理解 如 何 监控 应 用 

o 管理 集群 组 件 日 志 

o 管理 应 用 日 志 
Troubleshooting 问题 排查 10% 

o 排查 应 用 失败 故障 

o 排查 控制 层 (control panel) 故障 

o 排查 工作 节点 (work node) 故障 

o 排查 网 络 故障 


考试 说 明和 checklist 


e 注册 考试 
e 检查 系统 要 求 
e 选择 考试 日 期 
e 获取 考生 手册 
e 验证 姓名 
e 阅读 重要 提示 
e 参加 考试 


考试 期 间 ， 除 了 考试 系统 界面 上 的 内 容 和 按钮 能 操作 外 ， 其 它 的 最 好 不 要 动 。 所 
有 考试 无 关 的 内 容 和 资料 不 允许 出 现 ， 包 括 手 机 ， 参考 书 等 等 。 


考试 的 时 候 会 提供 一 个 Linux Server Terminal ， 是 基于 Gateone 的 web 终端; 一些 
快捷 键 可 能 跟 一 般 的 linux 终端 软件 不 一 样 ， 请 提前 了 解 和 体验 

考试 由 31 个 问题 组 成 ， 需要 你 用 命令 来 解决 这 些 问 题 

有 8 套 环 境 ，31 个 问题 在 这 8 套 环境 里 进行 操作 。 


平均 每 套 环 境 有 3~5 个 问题 。 
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图 片 - cka-question 


通过 kubectl config use-context 来 切换 不 同 的 环境 (集群 使 用 的 的 k8s 1.6.2 版 
A) 


获取 集群 信息 ， 要 指定 对 应 的 context， 如 kubectl get no -| name-hk8s-node-1 - 
-context=hk8s 


参考 官方 考试 手册 


FAQ 


1. 考试 费用 ? 


Kubernetes CKA 认 证 说 明 


300 美 元 ， 可 以 重 考 一 次 
2. 考试 时 间 长 度 ? 

最 长 4 个 小 时 ， 依 赖 考生 的 熟练 程度 
3. 如 何 监考 ? 


屏幕 共享 软件 可 以 让 监考 官 看 到 考生 的 屏幕 ， 所 有 的 音频 ， 视 频 和 屏幕 
共享 流 会 被 保留 一 段 时 间 ， 用 于 审查 


4. 系统 要 求 ? 


chrome 浏 览 器 ， 网 络 连 接 ， 网 络 摄像 头 和 麦克 风 这 个 连接 可 以 帮忙 检查 
系统 要 求 ， 注意 Select “Linux Foundation" as the Exam Sponsor and 
"CKA" as the Exam. 


5. 考试 期 间 ， 我 可 以 利用 什么 资源 么 ? 

只 能 打开 考试 页 面 以 及 Kubernetes 官 网 
6. 考试 期 间 是 否 可 以 做 笔记 ? 

可 以 做 笔记 ， 但 是 仅 限 于 在 考试 控制 页 面 上 的 工具 上 
7. 需要 什么 和 证件? 


包含 考生 照片 的 官方 认证 证 件 ， 比 如 护照 ， 身 份 证 ， 驾驶 证 等 (注意 ， 需 
要 证 件 上 要 有 你 的 英文 名 称 的 全 名 ， 对 中 国 居民 来 讲 ， 可 以 使 用 护照 ) € 
要 注册 一 个 Linux Foundation 的 账号 ， 到 这 里 注册 


8. 考试 如 何 打 分 ? 
24 小 时 内 会 自动 打分 ，72~75 小 时 内 会 邮件 发 送 认证 结果 
9. 认证 的 有 效 期 ? 
有 效 期 2 年 ， 在 过 期 之 前 需要 重新 考试 
10. 取消 和 重 订 
在 预定 考试 日 期 前 24 小 时 外 ， 取 消 或 重 订 ， 可 以 获得 完整 退 费 
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复习 资料 
Kubernetes-Learning-Resources 
Kubernetes-Certified-Administrator 

培训 课程 导 图 

新 手 训练 营 

Linux Foundation 提供 的 免费 入 门 课程 

有 个 CNCF 网 站 提供 了 免费 的 分 级 课程 和 课程 文档 


除了 认证 大 纲 内 容 外 ， 还 可 以 看 看 feisky 的 kubernetes 指 南 里 面包 含 了 上 述 认 证 的 
大 部 分 内 容 


该 课程 的 课程 大 纲 : 


Welcome & Introduction 

Container Orchestration 

Kubernetes 

Kubernetes Architecture - Overview 
Installing Kubernetes 

Setting Up a Single Node Kubernetes Cluster Using Minikube 
Accessing Minikube 

Kubernetes Building Blocks 

Services 

Deploying a Stand-Alone Application 
Kubernetes Volume Management 

Deploying a Multi-Tier Application 
ConfigMaps and Secrets 

Ingress 

Advanced Topics - Overview 

Kubernetes Community 

Final Exam 

ps: 个 人 觉得 这 个 课程 可 以 不 用 学 ， 直接 看 文档 就 行 了 o 


还 有 一 个 收费 的 课程 ($299) 


该 课程 的 课程 大 纲 : 


Kubernetes Fundamentals 
Chapter 1. Course Introduction 


Chapter 2. Basics of Kubernetes 
Chapter 3. Kubernetes Architecture 
Chapter 4. Kubernetes Installation and Configuration 
Chapter 5. Accessing a k8s Cluster and Using the API 
Chapter 6. Replication Controllers and Deployments 
Chapter 7. Volumes and Application Data 
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Chapter 8. Services 

Chapter 9. Ingress 

Chapter 10. Additional API Objects 

Chapter 11. Scheduling 

Chapter 12. Logging, Monitoring, and Troubleshooting 
Chapter 13. Third-Party Resources 

Chapter 14. Kubernetes Federation 

Chapter 15. Helm 

Chapter 16. Security 

ps: 个 人 觉得 这 个 课程 太 贵 了 ， 为 了 省 点 钱 ， 仔细 研究 下 文档 就 行 了 。 


培训 体系 


* CNCF Exam Certified Kubernetes Administrator (CKA) & Metrics 
6 .. Expert 


Kubernetes LFS258 Course Certification Preparation Training @ 





Advanced Domain Specific Training Calico 


O 5' Master [enm 


Kubernauts Training 
Plan eo 


Role Based Training 6 Proficient Operators 





Advanced Deployment Topologies 


(Certified Kubernautsio Practitioner (CKP)& | 
图 片 - cka-mindmap 
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